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

我一直在研究一个不能再被描述为"小"的项目(40多个月),一个团队不再被定义为"小"(约30人).我们一直在使用敏捷/ Scrum(1)实践,并且使用健康剂量的TDD.

我不确定我是从敏捷还是TDD中选择了这个,更可能是两者的结合,但我现在显然是在那些把调试视为难闻气味的人的阵营中.通过'调试'我不是指更抽象的概念,即弄清楚系统可能出现什么问题,而是指在调试模式下运行系统的具体活动,逐步完成代码以找出其他难以理解的细节.

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

认为调试模式是"标准"模式的人倾向于编写只能通过调试才能理解的代码,这会导致浪费大量时间,因为每次你在其他人开发的代码之上处理项目时,你首先花费相当多的时间来调试它(并且,因为没有涉及到错误......这个术语变得越来越荒谬) - 然后就会出现孤岛.所以我很想说服我的一些队友避免调试模式是一件好事(2).但是,由于它们习惯于处于调试模式,因此它们似乎没有看到问题.对他们来说,花费数小时调试别人的代码,然后他们甚至开始做与他们的新项目相关的任何事情是常态; 他们没有看到任何错误.另外,因为他们花时间'搞清楚'

帮助我想出一个让他们脱离黑暗面的计划!

提前致谢.

(1)也称为SCRUM(全部大写).抛开资本化论点,我认为必须使用术语后的星号,因为 - 毫不奇怪 - 我们的组织"调整"敏捷和Scrum流程以适应所有利益相关方的感知需求.所以,老实说,根据理论,我不会假装这是100%,但这不是我的问题.

(2)是的,总是会有时候,我们就必须在调试模式下得到的,我不是要绝对避免,只是..试图尽量减少我们要深入到它的次数.

如果你想说服你的同事你的编程实践更好,首先要证明你​​的生产力比你更有效,至少对于某些任务来说.然后他们会在你解释你如何完成这些工作时相信你.

有时也更容易专注于具体的事情.您的同事甚至会谈论"代码味道"吗？也许你可以专注于诸如"当ABC模块失败时,需要永远调试它;使用XYZ技术要快得多.这里,让我演示一下." 然后你可以提到你的基本原理,这是调试器是一个有用的工具,但通常还有其他更有用的工具.

这是一个交叉的帖子,因为第一次围绕它而不是别人对另一个问题的回答.对于这个问题,这是一个直接的答案.

调试降低了我们生成的代码的质量代码,因为它使我们能够以较低的准备水平和较少的心理训练来逃避.我从2000年初的一次意外控制实验中学到了这一点,我现在谈到了这个实验:

我作为Delphi程序员签订了合同,分配的第一个任务是编写一个概念上类似于报告引擎的模板引擎 - 使用Java,这是一种我不熟悉的语言.

奇怪的是,雇主非常乐意向我支付合同费用以花费数月时间熟练掌握新语言,但不会支付书籍或调试员的费用.有人告诉我下载编译器并学习使用在线资源(Java Trails非常好).

艺术和科学的黄金法则是,拥有黄金的人制定规则,所以我按照指示行事.我编辑了我的编辑器宏,所以我可以通过一次击键在当前编辑缓冲区上启动Java编译器,我找到了编辑器的语法着色定义,我使用正则表达式解析编译器输出并将光标放在报告的位置编译错误.当尘埃落定时,除了调试器外,我还有一个IDE.

为了跟踪我的代码,我使用了一种很好的老式技术,即在控制台中插入写入记录在代码中的位置以及我要检查的任何变量的状态.它很粗糙,耗费时间,一旦代码工作就必须拔出它,它有时会产生令人困惑的副作用(例如,强制初始化比其他情况下更早发生,导致代码仅在跟踪存在时起作用).

在这些条件下,我的类方法变得越来越短,定义越来越明确,直到通常它们完成了一个非常明确的操作.它们也倾向于专门设计用于简单测试,具有简单且完全确定的输出,因此我可以独立测试它们.

长期和短期是当调试比设计更痛苦时,阻力最小的路径是更好的设计.

将这一点从观察变为肯定的是该项目的成功.突然有预算,我有一个带有集成调试器的"适当"IDE.在接下来的两周内,我注意到了对先前习惯的回归,"草图"代码通过调试器中的迭代优化来实现.

注意到这一点后,我使用调试器代替了周到的设计重新创建了一些早期的工作.有趣的是,取消调试器只会稍微减慢开发速度,并且完成的代码质量要好得多,特别是从维护的角度来看.

不要误会我的意思:调试器有一个地方.就我个人而言,我认为这个地方掌握在团队领导者的手中,在需要找出一个谜团的时候被带出来,然后在人们失去纪律之前再次被带走.

人们不会要求它,因为那将是对同行面前的弱点的承认,并且解释需求和周围环境的行为很可能会引发解决问题的同行见解 - 甚至更好的设计免于问题.

所以,FOR,我不仅同意你的立场,我还有来自受控实验的实际数据来支持它.然而,它是一个相当小的样本.在我的结论可以支持之前,需要进行更精细的测试.

你为什么不采取我对你的团队所说的话并提出试验建议.你有比他们更多的数据(我只是给你),为了有一个可靠的基础与你不一致,他们基本上必须测试这个想法,唯一的方法就是让你的想法成为现实.

但是,你应该为它完全崩溃做好准备,因为整个事情都是基于开发人员在没有逐步调试的情况下有能力和经验来应对更强设计挑战的假设.

创建了逐步调试以使调试更容易.降低标准的直接影响是人才较少的人可以参与 - 如果你建造一个甚至可以使用的工具,你将会得到使用它的大肆 - 如果新开放的活动得到良好报酬,很多人都会使用它.

这会导致人才流失,因为他们通常会利用这些人才来做稀有和珍贵的事情,以便在不付出太多努力的情况下获得高薪,市场不想为了追求卓越而付出代价,因为它无法很好地区分人才.知道什么时候支付它是合理的.

另一个想法是:最近有关生产服务器问题的工作,无法安装调试器,已经证明了拥有代码库的重要性,维护不依赖于调试器的可用性.在没有调试器的情况下增长的代码就不那么麻烦了.当你可以改变主意时选择不使用它们,然后当你无法改变主意时它就不会那么糟糕.

由于我相当确信,这个问题并不是关于调试是否是一种难闻的气味.

那么,你当地的教会可能更适合你的问题.

除此之外,通过争论说服他们.然而,你可能想重新考虑一下你的原教旨主义立场,因为这与说服力完全相反.您可能想要做的一件事是在整个讨论中删除"调试"一词,并通过"单步执行代码"或类似内容来替换它,强调您反对无意识的猜测/拼凑练习探究您谴责而不是知情反思代码.

(我仍然不同意你的意见,但除此之外,你不想讨论这个问题.)

这里有些不对劲,但很难把手指放在上面.也许真正的问题是代码有其他气味使其难以理解.我同意使用TDD时,应该使用较少而不是更多的调试器,因为您将以较小的增量开发代码.但是,如果您无法查看代码并理解它,也许是因为设计过于耦合 - 需要太多相互关联的类才能使事情发生变化.

如果代码真的需要如此复杂以至于观察不够,那么也许你需要投入一些好的评论,解释发生了什么 - 尽管我更愿意看到重构的东西到不需要评论的地步.我怀疑调试器可能是一个症状,而不是问题.

我知道,对我来说,从传统的代码优先开发转换为测试优先开发已经减少了调试时间......而且这不是我想念的.通常我只会涉及调试器,当它不明显为什么我刚写的代码通过测试,没有.

我认为这里真正的问题是

认为调试模式是"标准"模式的人倾向于编写只能通过单步执行才能理解的代码

如果这是真的,应该是自然错误的,不应该讨论它.如果它不明显,那是因为他们没有看到如何改进编写得很糟糕的代码.展示它们,进行代码审查,以便以一种明确的方式展示如何重构代码,而无需单步执行.

一旦更好的代码被编写,代码步进将自动减少,它只是不起作用.人们仍然会编写错误的代码,如果他们避免单步执行它只会导致更多的浪费时间(该死的我希望我可以通过这个意大利面条乱七八糟),而不是更好的代码.