[译] 论 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 会追求卓越,并且自始至终关注最重要和最突出部分上的差异,并且从不会无谓地拖慢你的进度。这些都是你应该学习的。