google code review系列1 - code review的标准

最近公司在做Code Review，需要整理一些Code Review的文档和大家分享，下面是对Google Code Review文档的翻译过程中自己的感想，结合自己的理解，分享给大家，同时欢迎大家讨论，你们在公司是怎么做Code Review的。在以前公司虽然也有Code Review，但是都比较随意，可能花了时间，但是没有起到真正的作用，下面我们看看google是如何做的？

翻译：https://google.github.io/eng-practices/review/reviewer/standard.html

Code Review名词解释

缩写	说明
CR	code review
CL	change list，指这次改动
reviewer	cr的那个review人
Nit	全称nitpick，意思是鸡蛋里挑骨头
LGTM	"Looks Good to Me."的缩写，看起来不错，评审者批准CL时会这么说。

整个Code Review分成如下五个部分，本节主要讲述Google Code Review的标准。

目录

• google code review系列1 - code review的标准

• google code review系列2 - 在code review中寻找什么

• google code review系列3 - 浏览审查中的CL

• google code review系列4 - code review的速度

• google code review系列5 - 如何编写code review注释

• google code review系列6 - 处理code review中的pushback

首先Google对code review的标准定调：

Code Review主要目的是确保代码库的整体代码健康状况随着时间的推移而改善。Code Review的所有工具和过程都是为此而设计的。

Code Review的目的就是为了保证公司整体代码的健康状况，可以随着时间的推移，不断得到改善，所有在Code Review中的工具和过程都是为此目的而设计的。

为了实现这一目标，必须综合考虑许多因素，并做出取舍和平衡。

首先，开发人员必须能够在自己负责的任务上取得进展。如果你从未向代码库提交改进后的代码，那么代码库就永远不会得到改进。另外，如果一个reviewer使任何更改都很难进行，那么开发人员就不愿意在将来进行改进。

另一方面，reviewer有责任确保每个CL的质量，也就是说，不能让代码库随着时间的推移，整体的代码的质量逐渐降低，根据我个人的工作经历，其实很多公司都做的不好，可能因为进度等等问题，随着功能的越来越多，技术债的积累会越来严重。如何保证业务和代码质量共同发展，是值得我们深思的问题。

这可能很棘手，因为随着时间的推移，代码运行状况会随着时间的推移而略有下降，尤其是当团队受到重大时间限制，并且他们觉得必须走捷径才能实现目标时。

此外，reviewer对他们正在审阅的代码拥有所有权和责任。他们希望确保代码库保持一致性、可维护性，以及“在code review中寻找什么”中提到的所有其他内容。

因此，我们将以下规则作为我们在code review中期望的标准：

一般来说，当CL存在的时候，reviewer应该赞成它，CL肯定会提高正在运行系统的整体代码质量，即使这个CL并不完美。

这是所有code review指南中的首要原则。

当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，那么reviewer当然可以拒绝，即使代码设计得很好。

一个关键点是：没有“完美的”代码，只有更好的代码。reviewer不应该要求开发人员对CL的每一个微小的部分进行打磨。相反，reviewer应该在项目的进展和reviewer的改进建议两者之间做好权衡。reviewer不应该追求完美，而应该追求持续的改进。作为一个整体，提高系统可维护性、可读性和可理解性的CL不应该因为它不是“完美的”而延迟几天或几周通过审批。这是非常不利用业务发展的，所以个人觉得reviewer需要比较资深的工程师。

如果有些东西可以做得更好，reviewer 应该随时留下评论。但是如果该评论所建议的改进不是很重要，可以在前面加上“Nit:”这样的前缀，让作者知道这种改进只是一种锦上添花的效果，作者可以选择忽略。

注意：本文档中没有任何内容推荐合并会明显恶化系统监控状态的CL。只有在紧急情况下你才会那样做。

指导

code review在向开发人员传授语言、框架或一些通用软件设计原则具备非常重要的作用。留下评论，帮助开发人员学习新知识总是好的。这也是我前面为什么说code review最好还是有经验，比较资深的工程师。随着时间的推移，共享知识是改善系统代码健康状况的一部分。请记住，如果您的评论纯粹是教育性的，但对于满足本文档中描述的标准并不是至关重要的，那么在它前面加上“Nit:”，或者以其他方式表明并不强制作者在本CL中解决它。

原则

• 技术事实和数据，优先于个人观点和偏好。

• 在代码风格方面，如果公司已经采用了统一的代码风格，必须严格遵守，大家都知道，如果团队每个人的代码风格都不一样，造成的后果是任何的一点改动，如果格式化了代码，可能会对代码合并造成困难。代码风格应该与现有的一致。如果没有的统一风格，那就接受作者的风格。

• 软件设计的方方面面几乎从来都不是纯粹的风格问题，也不只是个人喜好。它们基于基本原则，应该根据这些原则来衡量，而不仅仅是个人观点。有时有一些有效的选择。如果作者可以证明（通过数据或基于可靠的工程原理）几种方法同样有效，那么审查者应该接受作者的偏好。否则，选择取决于软件设计的标准原则.

• 如果没有其他规则适用，那么reviewer可以要求作者与当前代码库中的内容保持一致，只要这不会恶化系统的整体代码运行状况。

解决冲突

在对代码评审的任何冲突中，开发人员和reviewer应该始终根据本文档的内容以及“CL Author 's Guide“和“Reviewer Guide”中的其他文档，尝试达成一致意见。

CL Author 's Guide：https://google.github.io/eng-practices/review/developer/

当达成一致意见变得特别困难时，在reviewer和作者之间进行面对面的会议或视频会议交流，将会有所帮助，而不是仅仅试图通过code review 评论来解决冲突。(不过，如果您这样做了，请确保将讨论结果记录在CL的评论中，以供将来的读者参考。)

如果这不能解决问题，最常见的解决方法就是升级。升级路径通常是更广泛的团队讨论，让TL参与进来，请求代码维护人员作出决策，或者请求Eng经理提供帮助。不要因为作者和reviewer不能达成一致意见而让CL无所事事。

接下来更新：在code review中寻找什么，欢迎大家留言讨论。。。

往期阅读

网络探测和诊断工具 - traceroute

云原生之可观测性-OpenTracing、OpenSensus、OpenTelemetry

云原生之可观测性 - APM概念及选型

大厂“断子绝孙式”、“养蛊式”招聘有多害人？

Kafka Producer全流程分析和思考

卷不动了，我选择降薪去外企来平衡工作和生活

HBase、Cassandra、LevelDB、RocksDB 相关数据结构是什么？

时间轮（TimingWheel）算法总结

快乐程序员、读书狂魔、爱撸代码、开源项目、硬核互联网技术分享

觉得写得不错，请点在看，谢谢！