作为卓越工程文化的一部分,Code Review 其实一直在进行中,只是各团队根据自身情况张驰有度,松紧可能也不一,这里简单梳理一下 CR 的方法和团队实践。
为什么要CR
- 提前发现缺陷
在 CodeReview 阶段发现的逻辑错误、业务理解偏差、性能隐患等时有发生, CR 可以提前发现问题。 - 提高代码质量
主要体现在代码健壮性、设计合理性、代码优雅性等方面,持续 CodeReview 可以提升团队整体代码质量。 - 统一规范和风格
集团编码规范自不必说,对于代码风格要不要统一,可能会有不同的看法,个人观点对于风格也不强求。但代码其实不是写给自己看的,是写给下一任看的,就像经常被调侃的“程序员不喜欢写注释,更不喜欢别人不写注释”,代码风格的统一更有助于代码的可读性及继任者的快速上手。 - 防止架构腐烂
架构的维护者是谁?仅靠架构师或应用 Owner 是远远不够的,需要所有成员的努力,所谓人人都是架构师。架构防腐最好前置在设计阶段,但 CodeReview 作为对最终产出代码的检查,也算是最后一道关键工序。 - 知识分享
每一次 CodeReview,都是一次知识的分享,磨合一定时间后,团队成员间会你中有我、我中有你,集百家之所长,融百家之所思。同时,业务逻辑都在代码中,团队 CodeReview 也是一种新人业务细节学习的途径。 - 团队共识
通过多次讨论与交流,逐步达成团队共识,特别是对架构理解和设计原则的认知,在共识的基础上团队也会更有凝聚力,特别是在较多新人加入时尤为重要。
他山之石
2.1 某大厂A
非常重视 Code Review,基本上代码需要至少有两位以上 Reviewer 审核通过后,才会让你 Check In。
2.1.1 代码评审准则
- 如果变更达到可以提升系统整体代码质量的程度,就可以让它们通过,即使它们可能还不完美。这是所有代码评审准则的最高原则。
- 世界上没有“完美”的代码,只有更好的代码。评审者不应该要求代码提交者在每个细节都写得很完美。评审者应该做好修改时间与修改重要性之间的权衡。
2.1.2 代码评审原则
- 以客观的技术因素与数据为准,而非个人偏好。
- 在代码样式上,遵从代码样式指南,所有代码都应与其保持一致,任何与代码样式指南不一致的观点都是个人偏好。但如果某项代码样式在指南中未提及,那就接受作者的样式。
- 任务涉及软件设计的问题,都应取决于基本设计原则,而不应由个人喜好来决定。当同时有多种可行方案时,如果作者能证明(以数据或公认的软件工程原理为依据)这些方案基本差不多,那就接受作者的选项;否则,应由标准的软件设计原则为准。
- 如果没有可用的规则,那么审核者应该让作者与当前代码库保持一致,至少不会恶化代码系统的质量。(一旦恶化代码质量,就会带来破窗效应,导致系统的代码质量逐渐下降)
2.1.3 代码审核者应该看什么
- 设计:代码是否设计良好?这种设计是否适合当前系统?
- 功能:代码实现的行为与作者的期望是否相符?代码实现的交互界面是否对用户友好?
- 复杂性:代码可以更简单吗?如果将来有其他开发者使用这段代码,他能很快理解吗?
- 测试:这段代码是否有正确的、设计良好的自动化测试?
- 命名:在为变量、类名、方法等命名时,开发者使用的名称是否清晰易懂?
- 注释:所有的注释是否都一目了然?
- 代码样式:所有的代码是否都遵循代码样式?
- 文档:开发者是否同时更新了相关文档?
2.2 某大厂B
- 在开发流程上专门有这个环节,排期会明确排进日程,比如5天开发会排2天来做代码审核,分为代码自审、交叉审核、集中审核。
- 有明确的量化指标,如8人时审核/每千行代码,8个以上非提示性有效问题/每千行代码。
2.3 某大厂C
- 推行 Code Owner 机制,每个代码变更必须有 Code Owner 审核通过才可以提交。
- 所有的一线工程师,无论职级高低,最重要的工程输出原则是“show me the code”,而 Code Review 是最能够反应这个客观输出的。
- 尽量让每个人的 Code Review 参与状况都公开透明,每个变更发送给项目合作者,及转发到小组内成员,小组内任何人都可以去 Review 其他人的代码。
- 明确每个人的考评和 Code Review 表现相关,包括 Code Review 输出状况及提交代码的质量等。
我们怎么做 CR
3.1 作为代码提交者
- 发起时机&