代码 Rototilling （代码旋耕）

KV 讨厌不必要的工作。

尊敬的 KV：

每当与我共事的一位程序员需要向函数添加变量，并且名称与先前使用的名称冲突时，他都会将所有先前的实例更改为新的不同名称，以便他可以自己重用该名称。这导致他的 diff 远大于它们需要的，并且让我非常恼火。每当我为此质疑他时，他都会说旧的用法无论如何都是错误的，但我认为这只是他的借口。

被变量困扰的人

尊敬的困扰者：

这种行为只是“非我发明症”的另一种幼稚版本，或者像 Nirvana 乐队所说的那样，“领地撒尿”。您完全有理由质疑这种反社会行为，因为它会导致错误跟踪的祸根：不必要的 diff。

良好源代码维护的目标之一是最大程度地减少不必要的文本更改，以便于找到更改的重要部分。尽管润色一下发现丑陋的代码可能是一个好主意，但除非所讨论的代码经常是问题的根源，否则通常不值得付出努力。“如果它工作正常，就不要修理它。” 如果它不工作，那么，您可能必须删除整个函数、模块或子系统并重新开始。

令我惊讶的是，在错误修复和代码旋耕之间确实几乎没有中间地带，但我发现一旦我在同一 100 行代码段中修复了第 10 个错误，我“仅仅修复损坏的部分”的诱惑就会崩溃，并且我知道是时候撕掉创可贴并进行一些手术了。

程序员进行与功能无关的文本更改的唯一其他原因是他们可以假装在工作。在开源项目中，这被称为“象征性提交”——进行微小的更改只是为了让你的名字出现在项目历史记录中。在公司环境中，这是一种提高你的 KLoc 的方法——自上次审查以来你更改的行数。无论哪种方式，它都是令人恼火和反社会的，我支持你努力阻止它。强调阻止。

尊敬的 KV：

与我共事的一个人启动了一个新项目，该项目依赖于一个大型开源项目。为了跟踪外部项目，我的同事将其存储在我们的内部源代码控制系统中，现在每次有人尝试更新代码时，客户端都必须遍历一个庞大的项目，以确保所有其他文件都是最新的。

版本消化不良

尊敬的版本：

除非对外部项目进行本地更改，否则根本没有理由将其存储在您的版本控制系统中。话虽如此，项目依赖于其他项目是很常见的——甚至是被鼓励的。大多数软件都是站在巨人的肩膀上构建的，显然您的项目选择了一个高个子来站立。

当然，正确的方法是为每个外部项目提供其自己的本地存储库。您可以向您的同事解释这是一种模块化形式。每个外部组件都被视为系统的模块，并在其自己的独立区域中维护。拆分每个项目使得在不可避免的下一个版本到来时更容易更新项目。能够保留外部项目的提交历史记录而不会将其与您的历史记录混合在一起，只是遵循此过程的额外好处。

不要将别人的源代码提交到您的内部存储库的另一个原因是，随着源代码控制系统的激增，另一个系统可能与您的系统不同，甚至可能不遵循相同的提交模型。有些人使用具有单调递增提交编号的集中式系统，例如 Subversion，而另一些人则使用具有哈希值的分布式系统，例如 Mercurial 和 Git。尝试将一个系统的提交映射到另一个系统是可能的，正如 git-svn 所展示的那样，但在这种特殊情况下，这是不必要的工作。KV 讨厌不必要的工作。

最后一个且经常被忽视的原因是不混合代码库的法律原因。某些代码的许可方式规定，必须将修改反馈给原始作者。尽管这些许可证中未提及在单个存储库中混合代码，但事实是，查看单个存储库的程序员会将其中包含的代码视为“所有东西都是一体的”，当程序员这样做时，他或她必然会将您的——可能是秘密的——配方与导入的代码混合在一起。良好的篱笆在源代码中以及在现实生活中都能成为好邻居。

显然，是时候将此代码从您的存储库中踢出去并在其他地方维护它了。

KODE VICIOUS，凡人称之为 George V. Neville-Neil，为乐趣和利润而从事网络和操作系统代码工作。他还教授各种与编程相关的课程。他的兴趣领域是代码探险、操作系统和重写你的糟糕代码（好吧，也许不是最后一个）。他获得了马萨诸塞州波士顿东北大学计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车手和旅行家，目前居住在纽约市。

最初发表于 Queue 杂志，第 9 卷，第 12 期—
在数字图书馆中评论本文