全文共1966字，预计学习时长6分钟
图源：Unsplash
小芯认识的很多程序员小哥哥小姐姐经常和小芯“诉苦”——“我好难啊”。
不是“死”在敲代码的途中，就是“倒”在代码审查的路上。
有时候，代码审查往往比敲代码更费力，更艰难。不怕bug太多，就怕bug藏得深，让你反复找啊找啊，嘿，就是找不着。
为了解救广大同胞于“水深火热”之中，今天，小芯就和大家分享一个有关代码审查的小故事和妙招。
图源：Unsplash
作为一名初级工程师，我擅长进行大范围的全面更改。我会发现问题，然后直接解决它。
这通常意味着我要发送大量的代码审查。我会一次性修改用户界面到数据库的所有内容。
我对自己能够将整个系统铭记于心而骄傲，为自己工作迅速而骄傲，同时也为我胆大、勇敢和处理大问题的能力而骄傲。
有一天，一位高级工程师把我叫到旁边，给予了我职业生涯中收到过的最佳代码审查反馈。他告诉我要将大量的代码审查分成更小的、渐进式的更改。
我当时感到十分愤怒，不明白他为何想让我分解自己的更改步骤。
我为自己的宏观思考能力而自豪。可是为何他却说我的工作遭透了。在我看来，制定渐进式计划只会拖慢我。
我还是不明白渐进式更改的诸多好处。但不管怎样，我很高兴得到这位资深工程师的指教。我也很高兴自己学会进行渐进式的更改。
现在它成为了我的有力武器。
制定渐进式更改的好处
进行渐进式更改有诸多好处。
· 合并冲突更少。更改的文件越多，其他人同时更改这部分文件子集的机率就越高。通过进行小的更改并快速的检查来避免合并冲突。
· 代码审查更加迅速。比起50多份文件，人们更容易审查5个文件。与那些需要10分钟面对面交谈再查看代码的更改相反，查看可以快速解释的更改要容易得多。工程师看到大量的代码审查内容可能会心生倦意，希望有其他人来做这样的工作。由此找到可以审查你大量代码的人会花费更多的时间。
· 航向修正更加简单。代码审查员可能不同意你选择的方向，他们可能会要求你重做所有事情。若你只花费了几个小时进行更改，这没什么大不了。但如果你已经花了两天甚至更多的时间完善最终方案，便会更加痛苦。
· 更快速的测试。如果你已经接触了从用户界面到数据库的所有内容，可能需要重新对整个产品进行测试。若你进行了细微的更改，可能只需对更改的部分进行测试。如果你需要处理大量代码审查反馈，或者在录入之前需要合并大量代码，它凸显的优势再明显不过了。重新测试所有内容会花费很长时间，尤其是在某些手动测试的情况下。
· 更少的错误。细微的更改意味着无需同时在脑海中装下所有内容。你可以专注于需要改进的地方，并确保成功完成（我见过一位工程师，面对巨大更改量，他感到手足无措，往往寄希望于事后再去检查和修正错误。千万不要成为这种人。即使没有客户注意到，也会惹恼其他的同事。他们将不再相信你的代码）
· 检修更加容易。如果你确实破坏了某物，细小的更改会使你更容易找到根源所在。
· 渐进式部署。如果你想知道如何在非停工期的情况下部署某事，则可能需要进行细微的、渐进式的更改（但这可能只是其中一部分）。
· 还原更改更加容易。故障时常发生。更改越小，还原便越容易。如果你进行了巨大的更改，之后又有几个人对相同的文件进行更改，那么你可能陷入对大量更改后的数据进行恢复还是进行也许无效的快速修复之间的选择痛苦。如果情况紧急，只需还原初始的不良更改会减轻人们不少的压力。
· 部署回滚更加简单。如果单个部署更新了网页服务并立即引入了依赖于服务的用户界面功能。只有先删除用户界面功能，才能还原服务更改。根据部署的工作方式，以零停机时间还原更改可能并非易事。最好自己进行并部署网页服务更改。
· 低风险。这是以上所有会产生的结果。
将它继续传递下去
那天从高级工程师收到的代码审查反馈是我目前整个职业生涯中收到的最佳工程反馈。
几年后，我遇到了另一位工程师，他一直在进行大范围而全面的更改。我将同样的反馈分享给他。他看起来对我很生气，我能理解其中原因。还未见证他的工作有任何提升，我便辞去了工作。
但我相信，他最终会感受到渐进式更改给他带来的好处的。
毕竟只有这样不断改进，才能成为更优秀的工程师。
你，学到了吗？
图源：Unsplash
推荐阅读专题
留言 点赞 发个朋友圈
我们一起分享AI学习与发展的干货
编译组：王小燕、王书晗
相关链接：
https://medium.com/better-programming/the-best-code-review-feedback-i-ever-received-43313a503517
如需转载，请后台留言，遵守转载规范
推荐文章阅读
长按识别二维码可添加关注
读芯君爱你