[译] 论 Code Reviews

原文请戳《On Code Reviews》

没有什么是完美的，代码也一样

Code Reviews 是工程项目中非常重要的一环。然而，某种情况下这事是非常繁杂的，尤其是当 Code Reviewer 们持有着自己的态度或定见时。如果 Code Review 的姿势不对，它很可能让程序猿们精疲力竭、士气低落，不必要地拖慢了很多事情的进度，有时候它的破坏能力会超出想象。提高人效是至关重要的。一名优秀的 Code Reviewer 要能做到在提高项目代码质量、可读性的同时，进一步提高团队人效。这是软件工程中至关重要的一项技能。本文将介绍一些对你行而有效的 Code Review 的方法和态度。

Reviewing Code 并不是 Writing Code

如果这篇文章只能说一条准则的话，那会是：Code Review 的目地不是让整个项目的代码看上去都像是你写的。Code Review 作用的是让你能对项目的大方向有所把控，同时确保项目的质量级别，并且——也许是最重要的——它是Code Reviewer 和 Code Writer(甚至团队中的其他人) 对项目进展状况最好的沟通媒介。不要只是为了让项目代码符合你的风格，而迫使 Code Writer 更改他们的代码。给出建议是好的；给出代码书写规范也是好的；但有时候对于其他程序员写出与你风格不是很一致的代码时，你也要有一定的宽容度。

多多使用代码工具

在 CI / CD 时使用现代化的代码工具如 Linters 和 Code Formatters (例如 Yapf 之于 Python 和 Prettier 之于 JS) 对代码风格、语法错误或格式错误进行自动化检测和捕获。以上的几点 Code Reviewer 完全不需要去关注，因为代码工具能出色完成这些任务。
此种模式不仅仅是提高效率上的胜利，更是开发文化上的一种胜利！代码风格经常是各方争论的源头。而代码风格指导却会常会过时，同时 Code Reviewer 们因为经验、视角和关注点的不同，他们对代码风格的判断经常也不一致。所以，用代码工具能解决这些冲突 。

不要让细节拖后腿

如果你要求被 review 人修改代码的原因是些细节或次要的代码风格问题，这是很不可取的。关注细节很重要，对产出的高要求并让事情变得更好同样重要，你确实应该关注这些。但是你绝不应该让这些细节拖慢了整个项目的进度。对这些细节问题给出批注，并通过这些 PR(Pull Request)。请相信同事们的自律程度，他们会在 Merge 前对这些细节作出正确的修改，或者他们对为什么要这么做已有足够的思考。如果有的同事频繁地犯这种细节错误，那确实是他有问题，你则需要找他谈谈了，或者在必要时，走一些正式反馈流程。

放下键盘，当面谈谈

尽量避免在 PR 时进行长篇大论地讨论，更要避免在 PR 过程中发生争执。如果你不能与 Reviewer 尽快达成一致，那么不要花太多时间思考你 PR 的下一则回复，花5分钟去找 Reviewer 聊聊，这总会比文字讨论更有效。同时还要记得将交谈结果备注到 PR 上。
值得注意的是，长篇幅的 PR 讨论有时适合在做出大幅度的系统更改时，用这些 PR 讨论将更改内容记录下来，以便相关人员了解。
注：这类 PR 讨论应该是有意而为之的

建立信任

Code Review 不过的根本原因偶尔会出自不信任。如果彼此缺少了信任，那么代码的好坏便不再重要。尤其是当 Code Writer 在试图更改别人的代码时。
信任不会马上建立，这需要一些时间。没有什么比切实践行优秀工程师的素养更容易建立信任的了：写出高质量的代码、写出易于管理的 PR、写出简练的 PR 摘要、写出很棒的测试计划并严格执行它们。如果你言行一致，别人会很快信任你，他们会很快通过你的 PR 并且认真读你的反馈。如此一来，多事上你会很顺利。

找到榜样

学习 Review Code 最有效的方式是找到擅长这方面的人并虚心向他们学习。这就像品味一样，需要时间的沉淀。那些最优秀的 Reviewer 会追求卓越，并且自始至终关注最重要和最突出部分上的差异，并且从不会无谓地拖慢你的进度。这些都是你应该学习的。