Kode Vicious - @kode_vicious
PDF粉刷自行车棚
一种结束毫无意义的编码争论的万无一失的技术
亲爱的 KV，
上周，我们一位较新的工程师检入了一个小程序，以帮助调试我们正在开发的代码中的问题。即使这是一个测试程序，也有几个人阅读了代码，然后对他们希望看到的更改发表了评论。代码没有任何重大问题，但对于正在检入的内容，它似乎产生了很多电子邮件。最终，线程中的评论比程序本身还要长。在线程的某个时刻，提交代码的程序员说：“听着，我已经检入了代码；你们现在可以随意粉刷自行车棚了，”然后拒绝再对代码进行任何更改。我可以理解他对吹毛求疵的评论感到沮丧，但他说的粉刷自行车棚是什么意思？
也许我想要绿色
亲爱的绿色先生，
自行车棚是您停放自行车的棚子，由于所有此类棚子都需要粉刷以保护它们免受天气影响，因此它们必须粉刷成某种颜色。颜色对某些人来说非常重要。好吧，这并不是你真正想问的。
不幸的是，您所目睹的是对代码库中简单更改的典型反应。您是否注意到，当有人检入一些复杂且通常是可怕的代码时，检入会迎来几乎震耳欲聋的沉默？这通常是因为应该审查此类代码的人只是没有时间。不幸的是，很多人确实有时间审查 10 行或 50 行的更改，并且由于他们对没有检查更大的代码片段感到内疚，他们就会对小的片段吹毛求疵。
C. Northcote Parkinson 首先解释了为什么会发生这种情况，他写了一本关于管理的书（Parkinson’s Law and Other Studies in Administration，Ballantine Books，1969）。他指出，如果您正在构建复杂的东西，那么很少有人会与您争论，因为很少有人能理解您在做什么。如果您正在构建一些简单的东西——比如自行车棚——大多数人都可以构建，那么每个人都会有意见。不幸的是，正如您所了解到的，仅仅有意见是不够的，但大多数人觉得他们应该表达自己的意见。
编写原始代码的工程师显然意识到他陷入了一个毫无意义的循环，并决定通过告诉人们随意粉刷棚子的颜色来摆脱困境。他或她可能非常确定没有人会真正改变棚子的颜色，但通过不参与毫无意义的循环，能够让人们回到忽略代码中更重要的部分，而这正是他们之前一直在做的事情。
KV
附注：有关自行车棚故事的另一个版本，请访问： https://freebsd.ac.cn/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING。
附注：我喜欢我的棚子是蓝色的。
亲爱的 KV，
我最近被我的老板训斥了一顿，因为我一次性对我们的系统进行了很大的更改。我不认为它太大了，只有大约 20 个文件和几千行代码，但我被迫撤回我的更改，然后以较小的块将其提交到我们的存储库。虽然我理解人们不喜欢大的更改，因为它们可能会破坏稳定性，但所有这些代码都是相互关联的，并且真的无法智能地分解成更小的工作块。根据您的经验，单次检入的最佳大小是多少？
大量代码行
亲爱的大量先生，
首先，我非常怀疑您会被您的老板训斥一顿。我确信人力资源部会对在工作场所脱掉工程师或任何其他人的衣服皱眉头。
更严肃地说，允许检入到源库中的更改应该有多大，这个问题没有明确的答案。某些功能或错误修复需要对代码库进行广泛的更改。
我认为许多经验不足的工程师——以及许多经理——都错误地认为，错误修复通常只需要更改少量代码行，而功能则需要大量代码行。如果大多数错误是由一个错误或其他难以找到但易于修复的单行代码引起的，那么这将是正确的，但事实并非如此。通常，一个错误会是普遍存在的，会感染整个代码库。普遍存在的错误通常是将错误的假设编码到整个系统中的结果，结果是修复会触及许多（如果不是大多数）文件。当需要进行此类修复时，一次性检入所有更改是有意义的。不同时在所有位置修复同一个错误几乎没有任何意义。
许多程序员遇到麻烦的地方在于他们有运行代码。运行代码就像一个运行句子。您正在开发一个功能，但随后您发现了一个错误，然后您意识到还有另一个相关的错误，并且您修复了第二个错误，这使您遇到了第三个问题，并且您也修复了该问题，与此同时，您的项目负责人正在要求您开始实现该功能时发现的第一个错误，因此您回到功能开发，但尚未检入任何修复，因为您需要完成该功能才能测试修复，最后，您像我们的读者一样，气喘吁吁，无法记住整个事情是从哪里开始的。
作为一名工程师的一部分，就是将大型系统或问题分解为足够小的块，以便您和您的大多数同谋——我的意思是同事——能够理解和消化。没有人愿意一次性阅读 20 个文件中超过 2,000 行的代码。您可能花了一个多星期的时间来开发该功能并修复这些错误，您不应该期望人们能够在几分钟内通过阅读您（我相信）冗长的解释性提交消息来快速了解您所做的事情。
分解大型提交的最后一个原因是，如果有人在您编写的某些部分中发现错误，则可能会回滚较小的更改并保留您已完成的其余工作。另一种方法是提交大量工作，然后修补修补修补，这很草率且令人不满意。
我的指导原则很简单。如果您更改了 API，那么请一次性更改它及其所有使用者。如果您修复了三个错误并添加了一个功能，那么您需要进行四次不同的检入。
KV
KODE VICIOUS，凡人称为 George V. Neville-Neil，为乐趣和利润从事网络和操作系统代码工作。他还教授有关编程相关主题的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学的计算机科学学士学位，并且是 、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行家，目前居住在纽约市。
© 2009 1542-7730/09/0600 $10.00
最初发表于 Queue vol. 7，no. 5—
在 数字图书馆 中评论本文
© 保留所有权利。