作为一名初级工程师，当我看到一些问题时，通常会主动去解决它们，因此我总会进行一些大范围的代码修改。

这意味着我需要发出大量的代码审查。在一次修改中通常会涉及到从UI到数据库的所有部分。

我对于自己能够维护整个系统而骄傲，也为自己的快速处理问题的能力而骄傲。同时也为自己的勇敢和解决重大问题的能力而自豪。

直到有一天，一位资深工程师把我拉到一边，给我提出了迄今为止我收到过最好的代码审查返回。它告诉我应该将巨型的代码审查拆分为更小的增量修改。

我第一反应是感到恼怒。我不理解他为什么要我这么做。我对自己解决重大问题的能力非常有信心！为什么他说我的工作做的不好？！一点一点的进行修改只会拖慢我的脚步！

虽然当时我还不知道小规模、增量修改的种种好处，但是我很庆幸当时听了这位高级工程师的意见，很高兴我开始学着进行小规模、增量的修改。

这种方法给我后来的职业生涯带来了巨大的好处。

增量修改的好处

进行增量修改有诸多好处，下面我来列举一些。

• 更少的合并冲突。 你改的文件越多，和其他人的修改发生冲突的可能性就越大，小规模的修改可以有效的避免冲突，即使有冲突时也能更快的解决。
• 更快的代码审查。 对代码审查人员来说，审查5个文件无疑要比审查50多个文件轻松许多。与那些需要面对面交谈十分钟才能开始看的代码相比，小规模的修改能够更快速的开始审查并且更容易解释。当审查人员面对大量的代码审查工作时，他们有可能会犯懒，非常希望能找个人替他们完成这项工作。因此你可能需要花费很长时间才能找到一个愿意审查你的代码的人。
• 更早的修正。 你的代码审查者可能与你的思路相左。他们可能会要求你重做所有的事情。如果你之前只花了几个小时进行修改，那么这对你来说可能不是什么大问题。但是如果你在这个问题上已经花费了两天时间，那么重做可能是一件非常痛苦的事情。
• 更快速的测试。 如果你的代码修改涉及到了从UI到数据库的所有层级，你可能需要对整个产品进行重新测试。而如果你只进行小规模修改，那就只需要测试你所修改的那部分。如果你需要解决很多代码审查反馈或者是合并很多代码时，这种好处就非常明显了。重新测试所有东西会花费大量的时间，特别是手动测试。
• 更少的bug。 小规模修改意味着你不需要同时将所有东西都装进脑子里。你可以专注于你进行优化的这一部分代码，保证你可以把它做到最好。（我曾经见过一个工程师，它对自己的大规模改动感到不知所措，后来他养成了检查和修复都追求完美的习惯。希望你不要成为那样的人，即使没人抱怨，但是你的同事将会慢慢变得不信任你的代码。）
• 更容易排除故障。 如果你需要改动一些代码，那么小规模的改动可以帮助你更加容易的定位问题。
• 增量部署。 如果你想要不停机更新，那么更小的、增量的改动会帮助你解决这个问题。（但这并不是全部解决方法）
• 还原更加简单。 当你写了bug时，你的改动越小，还原就更加简单。如果你合入了大量代码，并且其他人又在后来进行了改动，那么还原你的代码就会是一件非常痛苦的事情。也许你可以进行快速修复，但这并不是一定奏效，生产环境出现事故时，剔除有问题的代码会使团队的其他人更加放心。
• 部署回滚更加简单。 如果单次部署更新了web服务和即时生效的UI功能，那么如果你想要回滚后端服务就必须先要回滚UI的改动。由于这样部署方式，想要做到不停机更新可能并不容易。最好的办法就是把它们分别合入代码仓库并部署。
• 更低的风险。 这实际上是上述所有情况的结果。

为你的未来交学费

那天我从那位高级工程师那里收到的代码审查反馈，已经被证明是职业生涯迄今为止收到的最好的代码审查反馈了。

多年后，我遇到了另一名工程师，他一直在进行大规模、彻底的变更。我把相同的反馈分享给了他，他看起来很生我的气，但是我完全可以理解他。在我看到他有进步之前，我离开了那家公司，希望他最终能体验到小规模修改带来的好处。

相信他以后会是一名优秀的工程师。

译者点评