我一直在从事一个不能再用“小”来形容的项目(40 多个月)，以及一个不能再用“小”来形容的团队(约 30 人)。我们一直在使用敏捷/Scrum (1) 实践，以及适量的 TDD。
我不确定我是否从敏捷或 TDD 中学到了这一点，更可能是两者的结合，但我现在显然属于那些将调试视为坏味道的人的阵营。我所说的“调试”并不是指找出系统可能出现问题的更抽象概念，而是指在 Debug模式下运行系统的特定事件，单步执行代码以找出原本难以理解的细节。
因为我相当确信，这个问题不是关于调试是否是一个坏味道。相反，我想知道如何说服我的队友。
相信 Debug模式是“标准”模式的人倾向于编写只能通过调试才能理解的代码，这会导致浪费大量时间，因为每次您在某人开发的代码之上处理一个项目否则，您首先要花费大量时间对其进行调试(而且，由于不涉及任何错误......这个术语变得越来越荒谬) - 然后就会出现孤岛。因此，我很想说服我的一些队友，避免 Debug模式是一件好事 (2)。然而，由于他们习惯于 Debug模式，因此他们似乎没有看到问题；对他们来说，在开始做与新项目相关的任何事情之前花几个小时调试别人的代码是常态；他们不认为这有什么问题。另外，当他们花时间“弄清楚”时，他们知道最终该领域的开发人员将变得可用，并且该项目将被传递给他们(导致另一个筒仓)。
帮我想出一个计划，让他们摆脱黑暗面!
提前致谢。
(1) 也称为 SCRUM(全部大写)。撇开大写争论不谈，我认为必须在该术语后面使用星号，因为毫不奇怪，我们的组织“调整”了敏捷和 Scrum 流程，以满足所有相关利益相关者的感知需求。所以，老实说，我不会假装这根据理论是 100%，但这不是我问题的重点。
(2) 是的，有时我们不得不进入 Debug模式，我并不是试图绝对避免它，只是..试图最大限度地减少有时我们必须深入研究它。
最佳答案
如果您想让同事相信您的编程实践更好，请首先通过您的工作效率来证明您比他们更有效，至少在某些任务上是这样。然后，当您解释如何完成这么多工作时，他们就会相信您。
有时也更容易专注于具体的事情。你的同事甚至谈论“代码气味”吗？也许您可以关注诸如“当 ABC 模块失败时，需要很长时间来调试它；使用技术 XYZ 要快得多。在这里，让我演示一下”之类的细节。然后你可以提到你的基本原则，这是的，调试器是一个有用的工具，但通常还有其他更有用的工具。
关于调试是一种坏味道——如何说服他们？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/256047/