禅宗和代码维护

警告:这可能有点说教。如果是这样，那只是因为我对此感到有点沮丧。

在家收拾残局

这些年来，我们家有个坏习惯。当我们使用一个工具时，我们会忘记把它放回正确的位置。下次有人需要这个工具时，我们花在寻找它上的时间比用它完成手头任务所花的时间还要多。可悲的是，这是真的，即使是同一个人最后使用它。通常，买另一个比在某处寻找我们知道的那个更快。

我们最终得到了四个中型的飞利浦螺丝起子，三个有槽的，多个多余的钳子，扳手和插座适配器组;更不用说令人印象深刻的收集笔，橡皮筋，电池，以及诸如此类的东西，到处都是。

有一天，我们决定停止这种行为。我们为东西开辟了合适的地方，组织了我们所有的东西。我们把复制品捐给了慈善机构。我们尽力做到自律，每次使用后将工具和用品放回原位。完成工作的质量和带宽都提高了。压力、浪费的时间和金钱都减少了。

在一个商业车库做收尾工作

如果在商业车库工作的机械师把东西随意扔在那里怎么办?他们花在寻找工具和零件上的时间比完成这项工作所花的时间还要多。零件可能被放错地方、丢失、被盗、生锈或损坏。供给的成本会上升。

工作时间会上升，但质量会下降。使用生锈，磨损和破碎的工具，力学将难以适应和妥善处理部件。除此之外，将商店放在混乱中的心态肯定会反映在适用于工作的护理中。

客户将厌倦等待超越所承诺的工作时间。他们很快就会寻求更可靠的商店。Word将到处走来。

与软件开发/维护的联系可能是显而易见的。

解决软件中的问题

一个恰当的例子是:增量重构。

许多人似乎对此感到困惑。我不知道是“重构”这个词还是“增量”这个词导致了混乱。

增量重构是来自大规模重构的完全不同的东西。人们认为所有重构都是一样的;他们假设所有重构是“大规模”的，因为它需要来自某人的“许可”，它将总是导致工作要做得多时间。事实上，不随着时间的推移进行重构会使工作花费更多的时间。

大多数技术教练，包括我在内，很难弄清楚两者的区别;不是因为它本身就很复杂，而是因为它太明显了，很难用语言来解释。但我认为，我们记录工具和用品的经验提供了一个有用的类比。

增量重构

增量重构就像保持工作区整洁一样。这就像把螺丝刀放回原位一样。这不像你每次工作都要建一个全新的车库。这更像是完成工作的本质……真的完成……你开始。做收尾工作。

增量重构不会增加时间，也不需要任何人的明确许可。如果需要的话，你应该得到特别的许可不让代码保持整洁。对于软件工程师来说，在任何时候保持代码干净都应该被认为是基本的工作表现。人们不得不创造一个特殊的流行词来描述它，而如今的软件工程师却反对这样做，这是一种耻辱。

这绝对是不与之具有大规模的建筑重构的同样的事情做需要不同的规划和分配时间，金钱和人。

假设你和我们一样，决定把东西组织得更好，这样我们就不会浪费时间一遍又一遍地找同样的东西。第一次建立这个系统的努力相当于对软件进行“大规模”重构。我们需要“获得涉众的许可”，作为一个家庭，同意组织工具的存储，并记住每次使用后替换工具。

前进，当我们开始一个需要工具的任务时，后来把它们放回他们的位置不就像“大规模”重构。不客气。我们不需要召开家庭会议就把螺丝刀放回原位达成协议。我们就这么做。

童子军的规则

在软件工程中有一个所谓的侦察规则:留下代码至少和你发现时一样干净。同样的道理也适用于在家里储存我们的工具。如果，在寻找钳子的过程中，我们看到有槽的螺丝刀和十字螺丝刀互换了位置，我们就继续把它们互换到合适的位置。我们不需要正式的项目计划来做到这一点。

这也是增量重构的工作原理。我们在一段代码中添加一个新的case到条件列表中。我们看到这个列表被实现为一个大的if/else块。在添加新case的过程中，我们决定将其更改为switch或case语句。您可能会说，这不比if/else块好多少。你是对的:它不是多更好。但也有可能一个小更好。下次有人触摸那段代码，他们可以让它变得更好，因为你会把它们留在一个更好的起点。

如果你之前做过类似的事情，那么你可能会发现通过阅读所有的条件你会发现一些重复，一些低效的排序，可能一个永远无法达到的条件，甚至可能会有一个逻辑“洞”，允许控制通过if/else块，而完全不处理情况。幸运的是，你没有在半夜通过产品支持票据发现这一点;尤其是当您发现代码处于混乱状态时，而此时您更想睡觉。

也许我们向应用程序添加一些功能，我们注意到我们写入的函数或方法与代码库中其他地方的现有位置非常相似。即使没有由复杂的IDES提供的便利，它也只需要几秒钟即可占用这种重复。我们可以安全地重构，因为我们还应用了自律，以确保Microtests或单位测试覆盖该功能，即使我们用手重构。毕竟，辩解是什么不做那些东西吗？

“长期”并不像人们想象的那么长

我经常听到人们说重构的好处是“长期的”，虽然它在理论上是有意义的，但在这里的Real World®中，我们总是在紧张的时间表交付压力下。但是，当谈到通过增量地进行小重构来保持代码整洁时，“长期”指的是下一次接触代码库的那一部分。下一次。

在《黑暗面》中，反过来也是正确的。如果我们不当我们走开时，将代码清洁，损坏迅速累积。We don’t have a ten year “cushion” to accumulate cruft free of charge before the damage kicks in. The next change we make will take longer than necessary and will carry a greater risk of introducing a regression, and the situation will worsen if left unattended.

如果我们走捷径的原因是为了满足涉众对快速交付的需求，那么在我们确保不再能快速做出任何更改(因为我们已经允许代码陷入不可维护的状态)之后，我们如何提出满足需求的建议呢?

什么是快?慢是什么?

无论您提供多快，您的利益相关者都将永远希望发生更快的事情。最大限度地减少交货时间的最有效方式是做正确的事情;做得好;捆绑所有松散的末端，每一次都有。切入角落试图“更快”，只让我们走得更慢;不是在神话中“长期”，但立即。

当涉众说他们想要事情更快时，他们并不意味着他们想要事情草率。他们不会想到，他们必须一遍又一遍地告诉我们，他们的每一个要求，他们希望高质量。高质量是假定成为我们工作的一部分。

作为软件工程师，我们选择是否将增量重构视为我们专业工作的基准部分。我们不要求允许妥善处理我们的工作，任何外科医生都要求会计师是否需要花时间在操作前洗手。完成操作需要的时间是完成操作所需的时间正确。患者希望他们的阑尾能干净地取出来，恢复正常生活，没有感染，也没有植入手术海绵。提前十分钟走出手术室对他们没有什么好处如果他们会因此而出现并发症。

对这一观察的标准回应是说正常工作会花费太久。什么真的“需要太久”是恢复从事匆忙而无法申请尽职调查。从感染中恢复对患者的生命，家庭和工作产生了巨大影响。第二次操作以删除身体中留下的海绵，因为人们正在匆忙工作是更大的影响。

在软件工作中，由于仓促进行软件更改而创建五个回归并不能“节省时间”。相反，它会导致更改花费更长的时间:在完成之前，它不会算作“完成”正确的。如果团队需要花费数小时或数天的时间来解决问题，他们就不能把时间花在其他增值工作上;这是机会成本。

在时间和金钱方面存在涟漪效果，有时包括丢失的客户。技术人员的额外压力也有成本;低士气和高营业额，导致加强压力和压力的环路，降低士气和参与。

技术债务比喻

每当提到增量重构的主题时，总会有人提到技术债务的比喻。他们会说，考虑到我们必须交付的时间，我们必须抄近路。他们会说，这是一个出于商业原因而产生技术债务的例子。亚博vip9通道

这代表了对比喻的误解，也可能是一般的隐喻。

• 隐喻不是它引用的东西的完整和全面的定义。这只是一种帮助某人获得一般意义的速记方式。
• 人们倾向于用比喻来取代物品，并开始对待比喻，好像它是实际的事情。这不是。曾经。
• 人们还倾向于将隐喻的使用扩展到其原始语境之外。这削弱了隐喻的意义和用处。沃德·坎宁安(Ward Cunningham)在与金融服务行业的客户合作时提出了“技术债务”这个比喻。他在寻找一个能与他们产生共鸣的隐喻，来解释增量交付如何提供一个反馈回路来改进软件解决方案;不为了制造速度错觉而偷工减料。
• 技术债隐喻的最初概念包括了始终保持代码干净的假设。其理念是，随着人们对问题和解决方案的理解通过迭代开发得到改进，代码将处于允许更改的状态;不代码是不可靠的，由于技术原因需要修正。

为了更快地交付软件而走捷径与技术债务的比喻不是一回事。这不是一个由业务驱动的亚博vip9通道决策。这只是草率的工作。

谁决定?

实现快速交付的方法是消除我们路径的障碍。一个这样的障碍是Crufty代码。这是一种障碍，可以通过纪律的工作逐步去除。它不依赖于过程或方法，如“瀑布”或“敏捷”。我们选择每次触摸键盘时如何完成我们的工作。

我的观点是:做好工作，包括做好收尾工作，对客户、投资人、管理层、未来的维护者和我们自己都是有益的。