| 2021-03-08
Code Review 可能让你的代码合入速度变慢，但它也是向其他聪明且有经验的工程师学习改善自己代码质量的机会。
你如何从他们那里获得最大的收获呢？
目标当然是：让自己写的大多数代码都能在第一轮评审时就顺利通过，最多只有几个小问题。
但是，你要明智地使用评审者的时间，因为那是一个有限的资源。 如果他们发现的问题是你自己很容易就可以发现的，那么你就在降低团队的整体工作效率。
假如你的代码经常需要多轮评审，下面的这些内容也许会帮助你节省时间。
在你发起代码评审之前：
- 重新评估你的代码：
不要自动化测试用例一通过，就迫不急待地发起代码评审。退一步，尝试重新思考一下整个事情，问一下自己：设计是否可以清理干净？尤其是在一天工作快要结束之时，可以等等看第二天早上是否会有更好的想法。虽然此步骤可能会减慢个人代码变更的速度，但从长期看，会提高平均吞吐量。
- 使用一下非正式的设计讨论：
如果有些东西你还没有把握，可以通过结对编程、面对面交流，或者发出一个早期差异，请求他们帮助对整个设计做一次"预先评审"。
- 自我评审变更：
尝试从一个对代码不了解的人的角度尽可能严格地查看代码。 您的代码审查工具可以为您提供与IDE完全不同的代码视图。这可能会轻松地为您节约一些反复的时间旅程。
- 让代码变更容易理解：
一次提交多个变更会让代码很难被评审。当你做自我评审时，尽可能进行减少差异的简单变更。例如，将较大的一次重构和代码格式变更，做为两次代码评审提交。
- 在提交信息中不要隐藏重要信息：
把它写在代码里。稍后有人看这些代码时，他不太可能查看提交消息。
当你在收到代码评审意见并进行修订时：
- 解决某个稍微严重的问题后，自己再重新评估一下代码：
后退一步，用全新的视角看看代码。完成一次代码修订后，你通常可以找到由这些变更带给你的启发，从面再次改进你的代码。与任何重构一样，可能需要好几个步，才能达到最佳设计。
- 理解 为什么 评审者会给你提这样或那样的评审意见：
如果你不理解每个评审意见背后的原因，就不要进行修改，去找评审者沟通学习一下。
- 用 代码 回答评审者提出来的问题:
不要为了回复而回复，要使代码更容易理解（例如，改进变量的命名，将布尔值更改为枚举型）或添加注释。如果不这么做，在你后面维护这段代码的人可能也会有同样的疑问。
发表时间：June 19, 2017
原文作者：Tom O’Neill