如何建立良好的代码审查Committer机制？

【引言】

大家好，我们华为公司上下正在致力于进行可信软件开发的变革，其中重要的一环就是代码审查制度的建立, 在本文中我们来讨论一下代码审查Committer的问题。

【干净代码】

一般来说，我们程序员，工程师，架构师等等跟代码接触比较密切的群体对于代码都有很深的感情。我们希望我们的代码既要干净，复杂度又要尽可能的低，项目进展又快，以后维护起来也很轻松。

那么问题就来了，怎么才能保证代码既干净又简单再入库呢？相信参与过很多不同团队开发的同事一定深有体会，在不同的团队里面代码审查的方式各不相同。接下来我们就探讨一下行业内的现状。下面的案例都是根据本人实际参与过的项目进行描述和分析，内容中略去具体公司名称和技术细节。

【现状1：会议讨论模式 】

这种模式是指团队中尽可能多的成员参与到代码审查过程当中，以小组会议讨论的形式逐行分步骤的审查代码。

具体形式是大家共享一个电脑屏幕，对于新的更改进行讨论，如果有不同意见就提出来研究有没有更好的方案。如果没有异议的话，就提交代码，如果有问题，达成共识以后进行修改，修改完成以后再进行下一轮的讨论。直到代码入库。

【会议讨论模式优点】

这种模式的好处是有助于让每个成员互相了解其他成员的技术细节，包括每个人在做什么。并且对于团队成员之间相互了解和相互学习很有帮助。其中某个或某几个人的离职不会导致项目出现很明显的停滞。我们说如果整个项目的代码量不是很庞大的情况下，这是一个非常好的办法。很多大公司中很多团队在使用这种模式。

【会议讨论模式缺点】

现在说一下这种模式的缺点，它的最大缺点就是效率低。假如看一个代码审查需要一人一个小时，五个人的话就是五个人小时。这种时间的开销在很多公司是通过加班来实现的。长期使用的话会形成疲劳战术，导致每个人都很疲劳，最后也会影响到代码的质量。

【会议讨论模式的改进方案】

那么如何保留这种模式的好处又规避其缺点呢？下面是我个人认为的一种改进方案。代码提交者结合自己的代码讲解自己任务的内容，由项目组长或者代码审查专员给出审查意见。绝大多数时间其他人就是旁听，不过多讨论。

这种改进方案的一个前提条件是代码审查专员必须很了解整个项目的技术，包括里面的技术细节，只有这样才会提出有价值的建议和给出准确的结论。具备这种能力的代码审查专员必须具备很强的学习能力和深厚的行业经验。

【现状2：三人批准模式】

这种模式也是应用在大公司的团队当中。基本思想就是，对一个代码提交，只要你找到三个项目组成员给你批准信号就可以入库。一般来说，代码提交者会发出PR（Pull Request）的邮件给团队成员。每个收到信的团队成员都可以发出批准信号，提交者在收到三个批准信号以后，代码入库按钮被激活，此时可以提交入库。

【三人批准模式的优点】

相对而言节省了总的审查时间。不需要每个批准者预留时间做代码审查，谁有空谁审查，审查人选比较自由，一般来说是能者多劳。

【三人批准模式的缺点】

困境一，如果代码审查人员没有看透代码的情况下批准，容易造成低质量代码入库。这种情况存在于前端工程师批准后端工程师代码，反之亦然。由于缺乏全局知识，这种情况放任下去就会造成很多冗余的代码，冗余的代码会增加项目的复杂度，从而能增加后续开发和维护的负担。

困境二，如果审查人员观点无法统一，没有一个决断者，会导致代码迟迟无法入库。

困境三，代码风格不统一，代码质量不易保障，增加了维护的难度。

困境四，在跨时区的团队合作中要凑足三个代码批准者可能存在无谓地等待。

【三人批准模式的改进】

要让批准代码修改的三人有共同的理念，及时沟通，协同作战。这实际上要求动态的三个团队成员整齐划一，行动一致。在实践中这样的改进不太容易，常常流于形式。

再一个改进是改为一人批准模式。此人需要具备全栈的能力。从而可以纵观全局，做出准确判断。因此很强的学习能力是必不可少的。

【影响代码审查的因素： 项目进度】

很多团队在进行代码审查的时候，常常以项目进度为理由进行妥协，从而让自己不太满意的代码入库，认为以后可以再做重构。

现实的情况是，如果你当初在代码量不大的时候没有对不满意的代码进行重构，在代码量变大以后，你就更加没有可能去做了。

【影响代码审查的因素： 审查代码人员能力】

代码审查人员要从实际项目出发，有能力把握全局，给团队成员予以指导，告诉成员们什么样的代码是合格的代码。

代码审查人员要有能力对代码风格和标准做出决定，并且讨论并说服团队成员按照这个风格和标准执行。

具体的案例可能千差万别，可以具体问题具体分析，一般的参考标准如下：

1.     找一个通用的代码格式化工具，大家一起用一套工具，提交之前对代码进行格式化；

2.     代码的复杂度是不是控制在了最低程度？

3.     命名方式要统一；

4.     代码即注释；

5.     在TODO区域中要使用注释；

6.     代码提交工具和方式要统一，有UI界面工具的尽量避免使用命令行工具；

7.     在主要代码分支上，保持代码历史线性化，要避免代码历史交叉；

【一个假定案例的推演】

我们假定有一个项目，项目可大可小。要有项目Owner和项目的技术负责人。

项目Owner负责研究并提出业务需求；

项目的技术负责人要：

--- 研究技术选型；

--- 研究业务逻辑；

--- 搭好前后端的基础架构代码;

--- 至少要走通一个前后端协同工作的业务逻辑；

--- 代码审查

项目成员要按照已有的业务逻辑，在保持复杂度平行增加的情况下，添加更多的业务逻辑，技术负责人负责代码审查。

至此，一个项目就有了良好的开端。

当项目业务逻辑增加涉及到基础架构代码变动的时候，要考虑是否要把要增加的这部分业务逻辑独立出来作为一个工程或者服务。

独立的工程是指工具处理类相关，测试类相关,数据库管理相关等等。

独立的服务是指：

1.     前端页面相关，比如一套独立的管理系统。

2.     后端服务，比如对应独立前端的API系统。

3.     后端服务，消息通知系统，无任何前端待用的独立子系统。

【小结】

好了，本文中对于代码审查Committer机制做了抛砖引玉式的探索，从行业现状到改进方法和案例推演等各方面做了简要地阐述。希望对大家有所裨益。欢迎留言，讨论，批评，指正。

软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。