调试是一种难闻的气味——如何说服他们?

如果你想说服你的同事你的编程实践更好,首先要证明你比他们更有效率,至少在某些任务上是这样。当你解释你是如何完成这么多工作的时候,他们会相信你。

这是一个交叉的帖子,因为第一次它更多的是旁白别人对一个问题的回答 different question . 对于这个问题,这是一个直接的答案。

我们产生的代码是因为它允许 让我们以较低水平的 纪律这是我从一个朋友那里学到的 事故控制实验 2000年初,我现在讲述:

我接受了一份德尔福的合同 编码员,分配的第一个任务是 编写模板引擎的步骤 在概念上类似于报告 这是我不熟悉的。

奇怪的是,这位雇主非常生气 花几个月的时间熟练掌握 一种新的语言,但不会付钱 下载编译器并学习如何使用 在线资源(Java Trails) 很好)。

谁拥有黄金,谁就创造财富 规则,所以我按照指示进行。我 把我的编辑器宏装配好了所以我 可以在上启动Java编译器 当前编辑缓冲区具有单个 击键时,我发现语法着色 我的编辑器和我使用的 并将光标放在报告的 编译错误的位置。当 尘埃落定,我有一个小小的IDE 除了调试器什么都有。

为了追踪我的代码,我使用了旧的 插入法 写入已记录的控制台 任何我想检查的变量。信息技术 很粗糙,很耗时,是吗 一旦代码被删除,就必须被删除 副作用(如强迫) 提前初始化 仅在跟踪 存在)。

在这种情况下,我的班级 方法越来越短,越来越多 专为方便使用而设计 确定性输出,以便我可以测试 他们是独立的。

长话短说就是这样 设计,最小路径

是什么改变了这一观察 这项计划的成功是肯定的 项目突然有了预算和预算 我有一个带有 集成调试器。全程 恢复到以前的习惯,带有 调试程序中的迭代优化。

早期使用调试器的工作 精心设计。有趣的是, 拿走调试器的速度变慢了 只进行了轻微的开发,并且 完成的代码要好得多 质量,特别是来自 维护视角。

别误会我的意思:有一个地方 对于调试器。我个人认为 那地方在队里 失去纪律。

人们不会想要它的 因为那就是承认 在同龄人面前的弱点,以及 解释需要和需求的行为 解决问题的同行见解- 问题

所以,因为,我不仅同意你的观点,我有一个控制实验的真实数据来支持它。然而,这是一个相当小的样本。在我的结论得到支持之前,还需要进行更详细的测试。

你为什么不接受我对你的团队说的话,并建议进行试验呢。你有比他们更多的数据(我刚刚给了你),为了有一个可信的基础来反驳你的观点,他们基本上必须测试这个想法,唯一的方法就是尝试一下你的想法。

不过,您应该准备好让它全部崩溃,因为整个事情都是基于这样一个假设:开发人员有天赋和经验,能够在没有逐步调试的情况下迎接更强大设计的挑战。

创建单步调试是为了简化调试。降低门槛的直接效果是,人才较少的人可以参与——如果你建立了一个连傻瓜都可以使用的工具,你会让傻瓜使用它——如果新的活动获得了很好的报酬,他们中的很多人都可以参与。

这导致了人才的大量流失,因为他们通常利用这些人才做一些稀罕而珍贵的事情,以便在不太努力的情况下获得高薪,而市场也不想为优秀人才买单,因为市场无法很好地区分人才,从而知道什么时候买单是合理的。

因为我相当确信,这个问题不是关于调试是否是一种坏味道。

那么,你当地的教堂可能更适合回答你的问题。

撇开这一点不谈,用论据说服他们。然而,你可能想重新考虑你的原教旨主义立场,因为这与说服力恰恰相反。您可能想做的一件事是在整个讨论中删除术语“调试”,并通过逐步浏览代码或类似内容来替换它,强调您反对您所谴责的不知情的猜测/拼凑做法,而不是对代码的知情反思。

(我仍然不同意你的观点,但那不是重点,因为你不想讨论。)

我认为真正的问题是

相信调试模式是 这只能通过

如果这是真的,那显然是错误的,没有必要讨论它。如果不明显,那是因为他们不知道如何改进写得不好的代码。向他们展示,做代码审查,在那里你展示了如何以一种清晰的方式重构代码,而无需进行深入研究。

一旦编写了更好的代码,代码步进将自动减少 , 相反,它就是不起作用 . 人们仍然会编写糟糕的代码,如果他们避免重复,那只会导致更多的时间浪费(该死的,我希望我能一步一步地完成这堆乱七八糟的事情),而不是更好的代码。

我知道,对我来说,从传统的、代码优先的开发切换到测试优先的开发已经减少了调试所花费的时间……我并没有错过这一点。通常,我只会在不清楚为什么我为通过测试而编写的代码没有通过测试时才使用调试器。

非顺序逻辑 .

让他们相信另一种方法的优势的“计划”是建立 metrics 链接到您调试 功能 漏洞。

非回归

这样,您就不会完全放弃“调试”习惯,但您可以说服他们建立一套可靠的测试,让他们能够在需要时专注于真正有用的调试会话。

如果你考虑这一过程(度量),你应该知道它的实现涉及所有层次结构(利益相关者、项目经理、架构师、开发人员)。他们都需要被牵连在这些指标中,以便采取行动。

关于开发人员,您可以尝试提出以下建议:

• 关闭bug案例的一些新方法(仅在播放测试场景以复制该bug时关闭它,这意味着他们需要一个独立的测试,以便在需要时启动调试会话)
• 这些指标与管理层对它们的评估之间的明确关系(在同一个功能上反复调试是一种不好的做法)
• 建筑的

我认为这个问题的更好措辞应该是“非TDD是代码气味吗?”TDD似乎会减少在调试器中花费的时间,因为编写/失败/通过测试的时间更多。如果没有TDD,您更有可能在调试器中花费时间来诊断错误。

至少在VisualStudio中,使用调试器没有那么痛苦,因此您面临的挑战是向您的团队成员解释TDD将如何使他们的开发更加愉快、高效和成功。仅仅避免调试器可能不足以让团队切换开发方法。

就在路上,勇士。 调试不是问题所在,它是注释和/或文档化较差的代码和糟糕的架构。我在一个较小的团队中工作,但当一个bug出现时,我会逐步完成代码。通常,这是一个非常小的工作,因为应用程序是精心设计的,代码上的文档是清晰的。

话虽如此,让我们回到我的观点。希望团队不要调试。。。评论,评论。没有什么能抑制加快调试速度的冲动。当然,他们仍然会这样做,但他们更有可能跳过文档化良好的代码。

哦,虽然不用说,我还是会做的。代码中没有错误。:)

我同意上面那些表示“调试器问题”相对无关紧要的人的观点

在IMO中,开发人员最重要的两个目标是:

在你制定计划之前,你应该决定这个改变对你有多重要。尽管我同意调试是一种气味,但对于开发人员来说,调试也是一种非常普遍且根深蒂固的做法,因此说服他们停止调试并不容易或很快,而且有充分的理由。你想在这个话题上投入多少精力?

第二,你为什么要首先说服他们?如果你的动机是帮助他们,这真的是他们的首要问题吗?当你帮助别人的方式,他们 想得到帮助吗 , change becomes easy .

一旦你决定要继续你的变革计划,你需要考虑到不同的人对不同的事情有不同的看法。有些人已经相信尝试一些新的和令人兴奋的东西。一些人会被数字(指标)说服。有些人是在吃他们最喜欢的曲奇时被告知的(说真的!),有些人是从他们最喜欢的导师那里听说的。有些人通过在杂志上读到这方面的信息。有些人看到“其他人也在这样做”。等等,pp。

InfoQ对Linda Rising进行了一次有见地的采访: http://www.infoq.com/interviews/Linda-Rising-Fearless-Change . 她说得比我好得多。这本书也很好。

resistance as a resource -,有时它发生在意想不到的时间,所以总是这样 keep a sense of wonder .

@例如:您还有第二个问题,这里是:

遗憾的是,开发人员似乎对提高生产率不感兴趣(不管怎样,他们得到的报酬是一样的)

让他们想要 当他们没有(可见的)收获时,他们会更有效率吗?

通过调试设计软件是一种很好的做法 .

支持这种开发方式的环境数量很少:最著名的是Smalltalk。在Smalltalk中,您可以编写一个描述对象协议的测试,而无需实现这些方法。运行此测试将触发调试器,您可以将该方法添加到调试器中的正确类中,并可以继续单步执行代码,直到实现所有功能且测试为绿色。