作为一名初级工程师,当我看到一些问题时,通常会主动去解决它们,因此我总会进行一些大范围的代码修改。这意味着我需要发出大量的代码审查。在一次修改中通常会涉及到从UI到数据库的所有部分。
我对于自己能够维护整个系统而骄傲,也为自己的快速处理问题的能力而骄傲。同时也为自己的勇敢和解决重大问题的能力而自豪。
直到有一天,一位资深工程师把我拉到一边,给我提出了迄今为止我收到过最好的代码审查返回。它告诉我应该将巨型的代码审查拆分为更小的增量修改。
我第一反应是感到恼怒。我不理解他为什么要我这么做。我对自己解决重大问题的能力非常有信心!为什么他说我的工作做的不好?!一点一点的进行修改只会拖慢我的脚步!
虽然当时我还不知道小规模、增量修改的种种好处,但是我很庆幸当时听了这位高级工程师的意见,很高兴我开始学着进行小规模、增量的修改。
这种方法给我后来的职业生涯带来了巨大的好处。
增量修改的好处
进行增量修改有诸多好处,下面我来列举一些。
- 更少的合并冲突。你改的文件越多,和其他人的修改发生冲突的可能性就越大,小规模的修改可以有效的避免冲突,即使有冲突时也能更快的解决。
- 更快的代码审查。对代码审查人员来说,审查5个文件无疑要比审查50多个文件轻松许多。与那些需要面对面交谈十分钟才能开始看的代码相比,小规模的修改能够更快速的开始审查并且更容易解释。当审查人员面对大量的代码审查工作时,他们有可能会犯懒,非常希望能找个人替他们完成这项工作。因此你可能需要花费很长时间才能找到一个愿意审查你的代码的人。
- 更早的修正。你的代码审查者可能与你的思路相左。他们可能会要求你重做所有的事情。如果你之前只花了几个小时进行修改,那么这对你来说可能不是什么大问题。但是如果你在这个问题上已经花费了两天时间,那么重做可能是一件非常痛苦的事情。
- 更快速的测试。如果你的代码修改涉及到了从UI到数据库的所有层级,你可能需要对整个产品进行重新测试。而如果你只进行小规模修改,那就只需要测试你所修改的那部分。如果你需要解决很多代码审查反馈或者是合并很多代码时,这种好处就非常明显了。重新测试所有东西会花费大量的时间,特别是手动测试。
- 更少的bug。小规模修改意味着你不需要同时将所有东西都装进脑子里。你可以专注于你进行优化的这一部分代码,保证你可以把它做到最好。(我曾经见过一个工程师,他对自己的大规模改动感到不知所措,后来他养成了检查和修复都追求完美的习惯。希望你不要成为那样的人,即使没人抱怨,但是你的同事将会慢慢变得不信任你的代码。)
- 更容易排除故障。如果你需要改动一些代码,那么小规模的改动可以帮助你更加容易的定位问题。
- 增量部署。如果你想要不停机更新,那么更小的、增量的改动会帮助你解决这个问题。(但这并不是全部解决方法)
- 还原更加简单。当你写了bug时,你的改动越小,还原就更加简单。如果你合入了大量代码,并且其他人又在后来进行了改动,那么还原你的代码就会是一件非常痛苦的事情。也许你可以进行快速修复,但这并不是一定奏效,生产环境出现事故时,剔除有问题的代码会使团队的其他人更加放心。
- 部署回滚更加简单。如果单次部署更新了web服务和即时生效的UI功能,那么如果你想要回滚后端服务就必须先要回滚UI的改动。由于这样部署方式,想要做到不停机更新可能并不容易。最好的办法就是把它们分别合入代码仓库并部署。
- 更低的风险。这实际上是上述所有情况的结果。
为你的未来交学费
那天我从那位高级工程师那里收到的代码审查反馈,已经被证明是职业生涯迄今为止收到的最好的代码审查反馈了。
多年后,我遇到了另一名工程师,他一直在进行大规模、彻底的变更。我把相同的反馈分享给了他,他看起来很生我的气,但是我完全可以理解他。在我看到他有进步之前,我离开了那家公司,希望他最终能体验到小规模修改带来的好处。
相信他以后会是一名优秀的工程师。
译者点评
小范围的修改确实是很有必要的。我自己在做code review的时候看到那种几百行的代码修改也是很头疼的。作者对于小规模修改的好处总结的还是比较全面的,希望大家能有收获。
原文地址
https://medium.com/better-programming/the-best-code-review-feedback-i-ever-received-43313a503517