自从我开始我的开发人员职业生涯以来已经有 10 年了，我学到的最重要的习惯之一就是我称之为“参数化进步”的东西。如果可以的话，我会告诉年轻的我。
当您致力于更改系统（代码库是系统）时，更改比您原先计划的更多的方面是非常诱人的。假设您只想修复一个错误。你找到了罪魁祸首，但你也看到了一个命名错误的变量，一个可以拆分成两个的函数，一些代码风格的改变，一些库的更新，以及其他一些看起来像错误的东西。因此，您修复了所有这些问题，并做出了承诺。
这可能看起来很有效率，因为您一次完成了更多的工作，但事实并非如此。实际上恰恰相反。每次 git 提交只修复一件事会更有效率。选择一个方面或一个“参数”，然后仅更改它。然后，看看会发生什么，了解更改的效果，然后继续下一个参数。因此是“参数化进步”。
下图说明了这看起来有多么违反直觉。如果你一次改变很多东西（图中左侧），看起来你似乎在走捷径，从而更快地达到目标。而Parametric Progress（右侧）可能看起来像是绕了弯路。
你应该避免一次改变很多事情的明显原因是缺乏重点。不要去剃牦牛毛，不要让功能蠕变。只做你想做的事，别无其他。但我还有一个更微妙的原因。
系统是敏感的东西。一旦你改变了一个方面，系统的其他部分总是有可能以你感到惊讶的方式受到你的改变的影响。所以最好只改变一个方面，然后了解系统如何对这一改变做出反应。如果您注意到出现新错误，您可以确定它是由特定更改引起的，并且您可以更轻松地了解因果关系。但是，如果您一次更改多个方面并且出现新的错误，您不知道是哪个更改导致了它。通常即使代码样式更改也很可能导致错误。
当程序员完全被错误搞糊涂时，他们有时会谈论可怕的黑魔法。当系统的心智模型与系统的现实不同步时，就会产生黑魔法的感觉。一次改变很多东西并不容易让你了解这个系统。开发人员谈论太多有关编写代码的内容。学习代码要重要得多。与您的系统保持同步，您将更容易修复错误，更不用说首先防止错误了。使用诸如参数化进度之类的东西来改进您对系统的学习。