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

Question

我一直在从事一个不能再被描述为“小”的项目（40 多个月），而我的团队已经不能再被定义为“小”了（约 30 人）。我们一直在使用敏捷/Scrum (1) 实践，以及健康的 TDD。

我不确定我是从敏捷还是 TDD 中学到的，更可能是两者的结合，但我现在显然属于将调试视为难闻的人的阵营。通过“调试”，我指的不是更抽象的概念，即找出系统可能出现的问题，而是在调试模式下运行系统的具体活动，单步执行代码以找出原本难以理解的细节。

既然我相当确信，这个问题不是关于调试是否是一种难闻的气味。相反，我想知道如何说服我的队友。

认为调试模式是“标准”模式的人倾向于编写只有通过调试才能理解的代码，这会导致浪费大量时间，因为每次在某人开发的代码之上处理项目时否则，您首先要花费大量时间对其进行调试（并且，由于不涉及错误……该术语变得越来越荒谬）-然后发生了孤岛。所以我很想说服我的一些队友，避免调试模式是一件好事（2）。然而，由于他们习惯于在调试模式下工作，他们似乎没有发现问题。对他们来说，在他们开始做任何与他们的新项目相关的事情之前花几个小时调试别人的代码是常态；他们看不出有什么问题。此外，当他们花时间“搞清楚”时，他们知道在该领域工作的开发人员最终会变得可用，并且项目将被传递给他们（导致另一个孤岛）。

帮我想出一个让他们远离黑暗面的计划！

提前致谢。

(1) 也称为 SCRUM（全大写）。撇开大小写争论不谈，我认为必须在术语后使用星号，因为——不出所料——我们的组织“调整”了敏捷和 Scrum 流程，以适应所有相关利益相关者的感知需求。所以，老实说，我不会假装这是 100% 根据理论，但这与我的问题无关。

(2) 是的，总会有不得不进入调试模式的时候，我并不是要绝对避免它，只是..尽量减少有时我们必须深入研究。

Answer 1

如果您想说服您的同事您的编程实践更好，首先要通过您的生产力证明您比他们更有效，至少在某些任务上是这样。然后，当你解释你是如何完成这么多工作时，他们就会相信你。

有时也更容易专注于具体的事情。您的同事甚至会谈论“代码气味”吗？也许您可以专注于诸如“当 ABC 模块发生故障时，调试它需要很长时间；使用 XYZ 技术要快得多。在这里，让我演示一下”这样的细节。然后你可以提到你的基本原则，是的，调试器是一个有用的工具，但通常还有其他更有用的。

Answer 2

这是一个交叉帖子，因为第一次发布它更多的是对其他人对different question 的回答。对于这个问题，这是一个直接的答案。

调试会降低代码质量 我们生成的代码，因为它允许 我们以较低的水平逃脱 准备和较少的心理 纪律。我从一个 意外对照实验 2000 年初，我现在谈到：

我以 Delphi 的身份接受了合同 编码器，分配的第一个任务是 写一个模板引擎 概念上类似于报告 引擎 - 使用 Java，一种具有 我不熟悉。

奇怪的是，雇主相当 很高兴向我支付合同费率 花几个月的时间精通 一种新的语言，但不会付钱 书籍或调试器。我被告知 下载编译器并学习使用 在线资源（Java Trails 是 不错）。

艺术和科学的黄金法则 是谁拥有金子 规则，所以我按照指示进行。一世 得到了我的编辑器宏，所以我 可以在 当前编辑缓冲区与单个 击键，我发现语法着色 我的编辑器和我使用的定义 正则表达式来解析编译器输出 并将我的光标放在报告的 编译错误的位置。当。。。的时候 尘埃落定，我有一个小IDE 除了调试器之外的一切。

为了跟踪我的代码，我使用了旧的 老式的插入技术 写入记录的控制台 在代码中的位置和状态 我想检查的任何变量。它 很粗糙，很耗时，它 一旦代码必须被拔出 有效，有时令人困惑 副作用（例如强迫 比它可能更早的初始化 否则已经发生导致 仅在跟踪时有效的代码 存在）。

在这种情况下，我的班级 方法变得越来越短，越来越多 明确定义，直到通常他们 做了一个很好的定义 手术。他们也倾向于 专为轻松设计 测试，简单而完整 确定性输出，所以我可以测试 他们独立。

它的长短在于 当调试比调试更痛苦时 设计，最少的路径 阻力是更好的设计。

是什么从观察中改变了这一点 可以肯定的是 项目。突然有预算和 我有一个“合适的”IDE 集成调试器。在过程中 在接下来的两周里，我注意到 恢复以前的习惯，与 “草图”代码由 调试器中的迭代细化。

注意到这一点后，我重新创建了一些 早期使用调试器的工作 周到的设计。有趣的是， 拿走调试器减慢了 发展只是轻微的，并且 完成的代码要好得多 质量特别是从 维护角度。

别误会：有一个地方 对于调试器。我自己觉得 那个地方在团队的手中 领导者，在时代被带出来 迫切需要找出一个谜团，并且 然后在人们面前再次被带走 失去纪律。

人们不会想要它 因为那将是承认 在同龄人面前的弱点，以及 解释需要和需要的行为 周围的环境很可能会诱发 解决问题的同行见解 - 甚至更好的设计 问题。

所以，FOR，我不仅同意你的立场，而且我有来自对照实验的真实数据来支持它。然而，这是一个相当小的样本。在我的结论得到支持之前，还需要进行更详细的测试。

您为什么不接受我对您的团队所说的内容并建议进行试验。你有比他们更多的数据（我刚刚给你），为了有一个不同意你的可靠依据，他们基本上必须测试这个想法，而唯一的方法就是让你的想法一试。

不过，您应该做好一切崩溃的准备，因为整个事情的前提是开发人员有能力和经验在没有逐步调试的情况下应对更强大设计的挑战。

创建了逐步调试以使调试更容易。降低标准的直接效果是，天赋较低的人可以参与——如果你开发了一个连傻瓜都可以使用的工具，你就会让傻瓜使用它——其中很多，如果新的可访问活动得到了丰厚的报酬。

这导致有才华的人外流，因为他们通常用这种才能做稀有和珍贵的事情，以便不劳而获，而市场不想为卓越买单，因为它无法区分人才足以知道何时付费是合理的。

---

另一个想法：最近在生产服务器上遇到的问题（无法安装调试器）表明了拥有一个维护不依赖于调试器可用性的代码库的重要性。在没有调试器的情况下增长的代码要少得多。当您可以改变主意时选择不使用它们，然后当您无法改变主意时，它就不会那么糟糕了。

Answer 3

由于我相当确信，这个问题不是关于调试是否是难闻的气味。

那么，您当地的教堂可能更适合您提出问题。

除此之外，通过论据说服他们。但是，您可能需要重新考虑您的原教旨主义立场，因为这与说服力完全相反。您可能想要做的一件事是在整个讨论中删除“调试”一词，并将其替换为“逐步执行代码”或类似内容，强调您反对您谴责的无知的猜测/拼凑式探测实践，而不是对代码的知情反思。

（我仍然不同意你的观点，但那不是重点，因为你不想讨论。）

Answer 4

我认为这里真正的问题是

相信调试模式的人 “标准”模式倾向于编写代码 只能理解为 遍历它

如果属实，这显然是错误的，无需讨论。如果不是很明显，那是因为他们看不到如何改进写得不好的代码。向他们展示，进行代码审查，展示如何以无需单步执行的方式清楚地重构代码。

一旦编写出更好的代码，代码步进将自动减少，反之则行不通。人们仍然会编写糟糕的代码，如果他们避免单步执行它只会导致更多的时间浪费（我真希望我能单步执行这个意大利面条式的烂摊子），而不是编写更好的代码。

Answer 5

这里出了点问题，但我很难说清楚。也许真正的问题是代码有其他味道，很难理解。我同意使用 TDD 时应该少用而不是多用调试器，因为您将以小增量开发代码。但是，如果你不能看代码并理解它，可能是因为设计过于耦合——需要太多相互关联的类才能使事情正常工作。

如果代码真的需要如此复杂以至于观察不够，那么也许您需要投入一些好的评论，解释正在发生的事情——尽管我更希望看到事情被重构到 cmets 的地步并不需要。我怀疑调试器可能是一个症状而不是问题。

我知道，对我来说，从传统的代码优先开发切换到测试优先开发减少了调试时间……这不是我想念的。通常情况下，我只会在不明白为什么我刚刚编写的代码无法通过测试时才涉及调试器。

Answer 6

这听起来像是你说你不想有的论点，但我认为如果你想说服你的队友，你将不得不提出更有力的理由。我不明白你的反对意见。我经常单步调试我试图用调试器理解的代码。这是查看正在发生的事情的好方法。您还没有证明以这种方式使用调试器的人倾向于编写难以理解的代码。这样做的唯一令人信服的方法是通过某种案例/对照研究，该研究试图测量和比较使用不同调试器方法的人编写的代码的可读性。而且您甚至没有讲一个合理的故事来解释为什么您认为使用工具来理解代码执行往往会导致代码构建更加草率。对我来说，这是一个完整的不合逻辑。

Answer 7

让他们相信另一种方法的优势的“计划”是通过建立 metrics 与您的调试次数相同 针对不同错误的函数。

通过分析该指标的趋势，您可以说服他们非回归测试对于花时间写作更有用，并且将帮助他们更有效地调试。

这样，您不会完全摆脱“调试”习惯，而是说服他们建立一套可靠的测试，让他们在需要时专注于真正有用的调试会话。

如果您考虑这一行动过程（指标），您应该知道其实施涉及所有层次结构（利益相关者、项目经理、架构师、开发人员）。他们都需要参与这些指标才能对其采取行动。

关于开发者，你可以尝试建议：

• 一些关闭错误案例的新方法（仅在重现该错误的测试场景下关闭它，这意味着他们需要独立测试才能在需要时启动他们的调试会话）
• 这些指标与其管理层评估之间的明确关系（反复调试同一功能是一种不好的做法）
• 更多地参与架构决策：有时，了解一些功能或应用特性而不仅仅是类和代码可以促使开发人员更多地考虑黑盒测试而不是白盒测试（这更容易导致调试会话）
• 参与“运营架构”流程（您需要在其中部署您的应用程序，并进行完整的从前到后的集成测试）。同样，整个系统的大图可以帮助开发人员对功能而不是“代码行”更感兴趣

Answer 8

我认为这个问题的更好措辞是“非 TDD 是否具有代码味道？”由于编写/失败/通过测试花费了更多时间，TDD 似乎导致在调试器中花费的时间更少。如果没有 TDD，您更有可能在调试器中花费时间来诊断错误。

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

Answer 9

正确的道路勇士。 调试不是问题，它的注释和/或记录的代码和架构不好。我在一个较小的团队中工作，但是当出现错误时，我会逐步执行代码。通常这是一项非常小的工作，因为该应用程序经过精心计划，并且代码上的文档很清楚。

也就是说，让我们进入我的重点。希望团队不要调试...评论，评论评论。没有什么能比得上更快地调试的冲动。当然他们仍然会这样做，但他们更有可能跳过有据可查的代码。

哦，虽然它应该不用说，但无论如何我都会这样做。您的代码中没有错误。 :)

Answer 10

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

IMO，开发人员最重要的两个目标是：

1) 让软件做它应该做的事情。

2) 编写代码，让维护开发人员在 2 年后享受更改现有功能或添加新功能的经验。

Answer 11

在制定计划之前，您应该确定此更改对您的重要性。尽管我同意调试是一种气味，但它也是开发人员非常接受和根深蒂固的做法，因此说服他们停止这样做并不容易或快速——而且有充分的理由。你想在这个话题上投入多少精力？

其次，你为什么要首先说服他们？如果你的动机是帮助他们，那真的是他们的首要问题吗？当您以人们希望得到帮助的方式帮助他们时，change becomes easy。

一旦你决定要继续你的变革计划，你就需要考虑到不同的人会被不同的事情说服。有些人已经通过尝试一些新的和令人兴奋的东西而被说服了。有些人会被数字（指标）说服。有些人在吃他们最喜欢的饼干时被告知（说真的！），有些人是从他们最喜欢的大师那里听到的。有些是通过在杂志上阅读的。有些人看到“其他人也在这样做”。等等。

在 InfoQ：http://www.infoq.com/interviews/Linda-Rising-Fearless-Change，Linda Rising 对这个话题进行了深入的采访。她说得比我好。这本书也不错。

无论做什么，不要压得太紧，也不要放弃。变化可能会发生 - 特别是如果您使用resistance as a resource -，有时它会在意想不到的时候发生，所以总是keep a sense of wonder。

Answer 12

@FOR ：你还有第二个问题，这里是：

遗憾的是，开发人员似乎对提高生产力并不感兴趣（无论如何他们的报酬都是一样的）

您打算如何让他们希望在没有任何（可见的）收益时提高生产力？

Answer 13

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

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

这需要一个在运行时可用的编译器和一流的调用。它提供了非常短的反馈周期，并且是 Smalltalks 生产力的主要原因之一