谷歌开源代码评审规范：好坏代码应该这样来判断

谷歌开源了一套代码评审（Code Review）规范，它是谷歌一套通用的工程实战指南，几乎涵盖了所有编程语言与各种类型的项目，这个规范代表了谷歌长期发展以来最佳实战经验的集合，谷歌表示希望开源项目或其他组织能够从这套规范中受益。

代码评审，也称代码复查，如果一个团队正在使用任务分支工作流，那么在所有代码编写完成并通过自动化测试之后，在代码合并之前，就会启动代码评审。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平，代码评审的所有工具和过程都是为了这个目的而构建的。代码评审对于敏捷团队来说的作用如下：

代码评审共享知识
通过代码评审可以更好的进行工作评估
代码评审能让你享受休假
通过代码评审指导新工程师

既然代码评审要进行众多的检查，那么找一个优秀的评审者就非常重要了。一般对于变更列表的不同部分，都会有不同的评审者进行细致的审查。当然如果是结对编程，且你的队友能进行高质量的代码评审，那么这样写的代码一般可以视为已经过评审了。此外，我们也可以进行面对面的评审，评审者会问开发者一些问题。

根据谷歌的项目描述，代码审核规范为两套独立文档组成，代表了两方面内容的最佳实践：

代码评审者的指南
CL 作者指南

在其中一些文档中使用了一些术语，如下：

CL：表示“变更列表(changelist)”，意思是已经提交到版本控制或正在进行代码检查的一个独立的更改。其他组织通常称为“改变”或“补丁”
LGTM：意思是“在我看来不错(Looks Good to Me)”，这是代码审阅者在批准 CL 时说的

接下来我们来看看两份文档分别的主要内容是什么：

1.代码评审者的指南——如何进行代码评审

代码评审者指南本来是一个完整的文档，但作者将其分为了 6 部分，读者可根据需要阅读。

代码评审标准
代码评审希望达到什么
在代码评审中导航 CL
代码评审的速度
如何写审查的评论
处理代码评审的回退

2.CL 作者指南——CL 作者批准代码的评审指南

CL 制定者指南包括一些进行代码评审的开发人员的最佳经验，这些经验能够帮助你更快、更高质量地完成评审。

写一个好的 CL 描述
构建一些小的 CL
如何处理代码评审者的评论

在谷歌看来，代码审核的目的是确保谷歌代码库的整体代码健康程度。谷歌将以下规则作为代码评审的标准：

一般来说，一旦 CL 能提升整体代码的健康程度，那么即使 CL 不完善，评审者同样也应该倾向于批准该列表。这是所有代码评审指南中的高级原则。它也会有一些限制，例如，如果 CL 添加了一些评审者不需要的特性，那么即使代码做了不错的设计，评审者也应该不予通过。

没有所谓的“完美”代码，只有更好的代码。评审人员不应要求作者在批准前对 CL 的每一小部分过分完美。相反，评审者应该权衡向前继续开发的需求和修改建议的重要性。评审者要求的是持续性地改进，而不是追求完美的代码。CL 作为一个整体，如果它能提升系统的可维护性、可读性和可理解性，那么就不要因为它还不完美而推迟数天或数周更新。

评审者应该经常留下一些评论，以表达能导致更好性能的做法。如果这些做法并不是非常重要的，那么需要加上前缀「Nit:」，从而令代码作者知道这些内容是可以忽略的。

评审指导

代码评审有一个很重要的功能，即教开发者一些开发经验，不论是语言、框架还是一般软件设计准则。留一些评论总会帮助开发者学习一些新的知识，共享知识也是改善系统代码健康状态的重要部分。当然，如果评审者的评论仅仅只是教育性的，且对于标准要求不那么重要，那么还是要加上前缀「Nit:」的。

评审准则

技术事实和数据要优先于观点与个人风格。

在代码风格方面，谷歌的代码风格指南是最权威的参考资料。任何不在风格指南中的代码习惯，都属于个人风格，但我们应该保证基本的风格和谷歌风格指南是一致的。

软件设计方面几乎不会有纯粹的风格问题，或者纯粹个人的习惯问题。很多风格问题都基于一些基本准测，它们并不是简单地由个人观点决定的。此外，如果代码作者通过数据或基本工程原则证明了几种方法同样有效，那么评审者应该接受作者的风格。否则，偏好的选择还是取决于软件设计的标准原则。

如果没有其它适用规则，那么评审者可以要求作者的偏好与当前代码库保持一致，同时不对整体的代码健康水平产生影响。

解决冲突

在代码评审中，如果发生了任何冲突，第一步应该是开发者和评审者基于本项目的 CL 指南达成共识。当达成共识非常困难时，开发者与评审者应该面对面地交流，而不只是通过审查中的评论来交流。如果开会讨论还解决不了，那么就要扩大会议了，我们可以通过与代码维护人员、工程经理等开发者的交流，达成最终的共识。

如果想要深入了解谷歌的这套代码审核规范，可查看该项目。地址如下：

https://github.com/google/eng-practices

谷歌开源代码评审规范：好坏代码应该这样来判断相关推荐

云效Codeup代码评审中的代码协同
简介: 云效 Codeup 汇集了阿里巴巴最新的代码托管.代码协同技术,希望能够造福更多中国和世界的开发者. 大神说:"Show me the code",于是就有了代码评审. & ...
代码评审中的代码协同
简介: 代码评审中同样存在着"Talk is cheap. Show me the code",语言无力时,直接上代码吧.这就是我们今天要讨论的话题--代码评审中的代码协同. 作者 ...
Code Review(代码评审规范)
1.Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制,通过这个机制我们可以对代码.测试过程和注释进行检查. Code Review主要用来在软件工程过 ...
java 代码书写规范_代码书写规范和命名规范
上一篇给大家分享了一下,关于文档编写的几个概念.这篇文章阐述如果编写代码书写规范以及命名规范文档.[以java语言为例] 1.代码书写规范代码书写规范,能够让不同的人,写出相同风格的代码.很多人都看 ...
谷歌开源！一个格式化 Python 代码的好帮手！
大部分人使用Python中的代码格式化工具时都会选择autopep8之类的工具,这些工具可能有一定的局限性,比如不会重新格式化已经符合 PEP8 的代码. 而本文即将介绍的 Yapf,不仅能将代码格式 ...
Android 代码命名规范 -- 提高代码可以读性
项目是团队分工合作,代码可读性非常重要,在开发过程中,命名规范统一尤为重要,最好是团队中统一好大家命名方法,这样对于日后的工作会轻松很多. 在面试的时候,审核一个程序员的编程水平的时候,命名规范也是一 ...
java代码开发规范_java代码开发规范
一编码规范 1.1 命名规范代码中的命名均不能以特殊字符(如下划线.$#符号)开始或结束. 反例: _name / #Object 2. 代码中的命名严禁使用拼音与英文混合的方式,更不 ...
如何用度量数据驱动代码评审的改善
本文正文内容共计8000字,建议阅读时间:16-18分钟. 阅读本文你将收获: 1.为什么要做代码评审的背景介绍: 2.代码评审数据分析设计:过程+指标体系+分析方法和模型: 3.如何做代码评审数据分 ...
【原创】项目管理杂谈(1)：代码评审这点事，元芳你怎么看
为什么80%的码农都做不了架构师?>>> 申明:因学识有限,某些见解和观点或有不妥,如有冒犯还请见谅.如需与作者联系,见文章底部个人签名处,乐于交流.Q群:210285832, ...

谷歌开源代码评审规范：好坏代码应该这样来判断

谷歌开源代码评审规范：好坏代码应该这样来判断相关推荐

最新文章

热门文章