老后台的碎碎念（三）- CodeReview质量保障

背景

最近感觉团队的代码越来越不规范了，一提交就改动二十个文件。借这个机会，整理一下研发过程中 CodeReview 的主要流程，重新思考下。

为什么要进行 CodeReview

要回答这个问题，先看看如果没有 CodeReview 会带来哪些问题。

代码维护责任人缺失

一般来说，写这段代码的人是主要责任人，评审人则是备份责任人。

备份责任人的作用是在主要责任人因休假、离职等原因缺位时，能够补位，处理线上问题等。如果没有备份责任人，一旦线上出现问题需要修改这段代码（尤其逻辑复杂时），你只有两种选择：

• 让休假的同事处理：一方面他可能不方便，效率低或者根本做不了，另一方面体验很差，不利于团队稳定。
• 自己处理：但你对这段逻辑不熟悉，效率低且容易出错。

有了备份责任人就容易多了。如果你作为评审人对评审过的代码还不熟悉，那只能说明你不合格。

我们就是要营造一种“休假你就安心休，其他兄弟能顶上”的团队氛围。

缺乏代码评价标准

以前我们常说某段代码写得很烂，像坨屎一样，但每个人的审美不同，没有统一标准，就很难客观评价别人的代码。

有了 CodeReview 和统一的代码规范后，评价标准就明确了，大家也无法随意反驳。

CodeReview 的目的

保证稳定性

没有经过 CodeReview 的代码和经过 CodeReview 的代码，哪个更容易出现 bug？

肯定是没有经过 CodeReview 的代码。多个人一起检查，总归更可靠。

通过在开发环境进行 CodeReview，可以提前发现并修正一些个人疏忽导致的 bug，避免这些问题上线，从而提升服务的稳定性。

提升技术氛围和代码质量

代码规范之所以这样规定，肯定有其道理，都是经过实际经验检验的。

按照规范进行 CodeReview，可以在一定程度上提升代码质量，减少低级错误的发生。

同时，这也是大家一起讨论代码的机会，有助于提升团队的技术氛围。

给高等级同事参与的机会

高等级的同事通常比较忙，没太多时间参与一线开发，这其实浪费了他们多年积累的开发经验。

通过 CodeReview，高等级同事也能参与进来，进行指导，一方面提升代码质量，规避问题；另一方面也让他们有机会了解一线业务。

这是一种双赢。

CodeReview 过程中的规定

MR 必须有评审人

合并到 master 分支的代码必须指定评审人，否则不能提交。

master 分支的代码会发布到线上环境，必须严格把关。

另外，评审人应尽量做到分散且固定。

“分散”指的是评审人分布要广，不要都指定同一个人，否则他精力有限，CR质量会下降。

“固定”是指同一个功能模块尽量由同一个人全程负责，避免今天是他，明天又换人，这样每个人都要重新熟悉业务，增加了成本。

评审人负有连带责任

评审人不能抱有侥幸心理，比如“今天太累了，随便看看点个通过得了”。如果这段代码有 bug，导致线上事故，是逃不掉责任的。

如果你的队友出了一级事故，你很可能要承担四级事故责任。

所以我们要认真审查代码，态度要端正。真出了问题，也只能心服口服，毕竟你也没发现。

代码规范要有

前面说过，必须有统一的代码规范，否则对方不服气。

“你说屎山就屎山啊？我看你的代码才像屎山。”

这种情况很容易出现。

代码规范只是CR的最低标准，并没有规定上限。有些团队会采用比规范更严格的标准，这也是可以的。

代码规范在团队交接时也很重要。应避免“自己看吧，都在代码里了”这种交接方式。如果对方代码不符合规范，你可以拒绝接手。

如何做

重视文档和单元测试

评审时，如果遇到不熟悉的业务模块怎么办？你会先看什么？

答案是先看设计文档、接口文档和单元测试。

复杂接口应在文档中说明方案，并提供运维指南。一方面，评审人可以根据文档判断是否存在其他风险；另一方面，可以通过测试用例了解接口代码的调用方式，减少review工作量。

增量评审，小步快跑

每次评审的内容不要太多，改动太大很难看完，花费时间长，对评审人也是负担。

也不要等到快上线时才提交CR，因为时间紧迫，评审人可能无法仔细检查。

建议以较小的粒度进行评审，比如将一个小功能模块作为最小单元。代码改动量尽量控制在500行以下。

集体参与

CR不仅是防范风险的手段，也是代码学习的机会。鼓励大家多参与，可以让成员了解功能实现思路，同时提升系统设计能力。

数据统计与复盘

在日常CR流程中，应增加数据统计，以便了解当前CR的质量，发现需要改进的地方。

一般统计维度包括：

• 比例：每天每位同学提交了多少 commit，有多少经过 review
• 质量：千行代码评论数。一直为0说明走过场，持续偏高说明质量较差
• 耗时：评审的响应时间和消耗时间

有了这些数据后，可以定期进行复盘。

总结

想要写出高质量的代码，除了依靠流程，更重要的是要有认真负责的态度。

归根结底，CR主要是为了保障系统的稳定性，提升技术能力只是附带的效果。