Code Review 标准

代码审查的主要目的是确保逐步改善 Google 代码库的整体健康状况。代码审查的所有工具和流程都是为此而设计的。

为了实现此目标,必须做出一系列权衡。

首先,开发人员必须能够对任务进行改进。如果开发者从未向代码库提交过代码,那么代码库的改进也就无从谈起。此外,如果审核人员对代码吹毛求疵,那么开发人员以后也很难再做出改进。

另外,审查者有责任确保随着时间的推移,CL 的质量不会使代码库的整体健康状况下降。这可能很棘手,因为通常情况下,代码库健康状况会随着时间的而下降,特别是在对团队有严格的时间要求时,团队往往会采取捷径来达成他们的目标。

此外,审查者应对正在审核的代码负责并拥有所有权。审查者希望确保代码库保持一致、可维护及 Code Review 要点中所提及的所有其他内容。

因此,我们将以下规则作为 Code Review 中期望的标准:

一般来说,审核人员应该倾向于批准 CL,只要 CL 确实可以提高系统的整体代码健康状态,即使 CL 并不完美。

这是所有 Code Review 指南中的高级原则。

当然,也有一些限制。例如,如果 CL 添加了审查者认为系统中不需要的功能,那么即使代码设计良好,审查者依然可以拒绝批准它。

此处有一个关键点就是没有“完美”的代码,只有更好的代码。审查者不该要求开发者在批准程序前仔细清理、润色 CL 每个角落。相反,审查者应该在变更的重要性与取得进展之间取得平衡。审查者不应该追求完美,而应是追求持续改进。不要因为一个 CL 不是“完美的”,就将可以提高系统的可维护性、可读性和可理解性的 CL 延迟数天或数周才批准。

审核者应该随时在可以改善的地方留下审核评论,但如果评论不是很重要,请在评论语句前加上“Nit:”之类的内容,让开发者知道这条评论是用来指出可以润色的地方,而他们可以选择是否忽略。

注意:本文档中没有任何内容证明检查 CL 肯定会使系统的整体代码健康状况恶化。您会做这种事情应该只有在紧急情况时。

指导

代码审查具有向开发人员传授语言、框架或通用软件设计原则新内容的重要功能。留下评论可以帮助开发人员学习新东西,这总归是很好的。分享知识是随着长年累月改善系统代码健康状况的一部分。请记住,如果您的评论纯粹是教育性的,且对于本文档中描述的标准并不重要,请在其前面添加“Nit:”或以其他方式表明作者不必在此 CL 中解决它。

原则

  • 基于技术事实和数据否决意见和个人偏好。
  • 关于代码风格问题,风格指南是绝对权威。任何不在风格指南中的纯粹风格点(例如空白等)都是个人偏好的问题。代码风格应该与风格指南中的一致。如果没有以前的风格,请接受作者的风格。
  • 软件设计方面几乎不是纯粹的风格或个人偏好问题。软件设计基于基本原则且应该权衡这些原则,而不仅仅是个人意见。有时候会有多种有效的选择。如果作者可以证明(通过数据或基于可靠的工程原理)该方法同样有效,那么审查者应该接受作者的偏好。否则,就要取决于软件设计的标准原则。
  • 如果没有其他适用规则,则审查者可以要求作者与当前代码库中的内容保持一致,只要不恶化系统的整体代码健康状况即可。

解决冲突

如果在代码审查过程中有任何冲突,第一步应该始终是开发人员和审查者根据本文档中的 CL 开发者指南审查者指南达成共识。

当达成共识变得特别困难时,审阅者和开发者可以进行面对面的会议,或者有 VC 参与调停,而不仅仅是试着通过代码审查评论来解决冲突。 (但是,如果您这样做了,请确保在 CL 的评论中记录讨论结果,以供将来的读者使用。)

如果这样还不能解决问题,那么解决该问题最常用方法是将问题升级。通常是将问题升级为更广泛的团队讨论,有一个 TL 权衡,要求维护人员对代码作出决定,或要求工程经理的帮助。 不要因为 CL 的开发者和审查者不能达成一致,就让 CL 在那里卡壳。