关于CodeReview的一些思考

我们很多人都以为CodeReview不重要，因为其他人写的代码和自己的关系可能不是太大，review的时候也不会上心，但事实上这个想法打错特错。CodeReview和我们的日常开发息息相关，缺少了它，那你的项目就是不完整的了。 本文作者Yezhiwei，我做了一些适当补充。

背景

上图为[产品迭代开发协作流程]，其中我们在 Demo 本次迭代之前会对开发人员的代码进行评审，所以今天就聊一下关于CodeReview的一些思考。

Code Review 的主要目标

• Code Review，也就是我们常说的代码评审。Code Review 主要是在软件开发的过程中，对源代码进行评审，其目的是找出并修正软件开发过程中出现的错误，保证软件质量，同时也能提高开发者自身水平。

• 代码写不好，可能是对业务不了解，对编程语言不熟悉，也可能对公司代码整体架构不熟悉，我们要找到原因并提出改进的解决方案。

• 正视 Code Review，不仅仅是过一个流程，而是能从中学习到些什么。

• 备份，多一两个人熟悉这块业务代码，避免最初的开发者休假等情况发生时，没有人能顶上来。

Code Review 带来哪些好处

从开发者的角度来看

1. 开发工程师需要按合理的逻辑化分，分模块从原始需求，然后是方案，最后是代码实现的进行讲解。

2. 这个过程需要的能力：对需求的理解（有助于合理化分功能）；表达能力，怎么说才能让评审的同学听懂你传递的信息；逻辑能力，是否有明的逻辑错误；心理压力承受能力，随时会有同学进行提问；

3. 作为开发者要时刻提醒自己，代码不仅是给机器读，还是要给人看的，所以代码的可读性也要考量，提交代码的信息是否写得非常清楚、合理。想想什么样的代码最想让你骂娘？哈哈... 爱美之心，人皆有之。漂亮的代码，也是我们的追求，它不仅能够完成要求的功能，而且还要整齐，有条理，易于理解。

4. 分享在这次需求开发过程中运用到的高级技术或一些奇淫巧技。

5. 代码被 Code Review 后，评审者也相当于参与了这次开发，相当于“备份”，当你休假或正在忙别的需求的时候，这时“备份”就能帮上你的忙了。

6. 对开发者的一个要求，大家统一代码风格，方便后期的维护。不推荐使用开发工具的自动格式化，手动调整会更好些，也能避免代码冲突。

从评审者的角度来看

审核的粒度要多细？每次评审花多少时间？具体哪些地方需要评审？

1. 代码格式方面：大家约定俗成，避免公司的代码风格不一致，新同学在这方面不太熟悉，就有可能出问题，但这类问题比较容易解决。

2. 代码可读性方面：方法不要太长；变量名、方法名要能说明它的用户和类型；不要有嵌套太多层的条件语句或循环语句；循环语句中避免调用远程服务或比较耗时的方法；如果不可避免有一些注释，一定要保证注释准确且与代码完全一致。

3. 业务边界和逻辑问题：思考一下有没有漏掉任何业务边界和逻辑问题。对现有业务是否有影响等。

4. 错误处理：有没有对参数验证？远程调用超时或服务不可用时，有没有默认的补救错误？数据库保存出错有哪些影响？

5. 代码质量和规范：遵循公司的编程规范，如：有重复代码段，就应该提取出来公用；不要在代码里随意设置常数，所有的常数应该在顶部统一定义或有专业的类；哪些变量是私有的、哪些是公有的，等等。

6. 代码架构：包的组织方式，是否和代码库的风格一致，API 的定义是否 RESTful 等等。

评审者能学到什么？

1. 深入了解需求及全局的信息架构。

2. 锻炼了自己的逻辑思维。

3. 学习开发者的一些奇淫巧技。

4. 即使没有参与具体的代码开发，但是可以一起与开发者背锅了，哈哈。

从参与者的角度来看

参考者有哪些收获呢？

理论上也应该和评审者没有任何区别。

但是，如果心态和情绪不对的话，可能会变成下面的情况了：

1. 有了了解需求及全局的信息架构机会。

2. 学习开发者的一些奇淫巧技的机会。

3. 可能有了一段带薪刷手机的时间机会，哈哈。

总之，还是看心态，如果在你心中觉得只是一个流程、混个过场，或者带着情绪来做这件事，可能也只能收获这些“机会”，没有达到期望的效果。

Code Review 推荐流程

代码提交

我们现在用的 gitLab 的代码仓库，在每次提交代码的时候，要说明清楚提交的代码到底是什么功能，方便有针对性的代码审核，一般代码提交分四类：

1. bug 修复，一般需要关联 bug 系统里对应的编号

2. 代码优化，如重构、移动、拆分方法等

3. 新功能开发，一般会和需求文档、设计方案关联

4. 系统迁移，如拆分出更多的项目，分别提交到代码库

发出合并请求，而不是直接合并代码

可以利用 gitflow 中每个分支的生命周期和使用规范，Meger Request 是一次代码提交请求，提交后，其他工程师可以在这次请求中提出修改建议，也可以针对某一些代码的发动进行讨论或是整体的评价。

Code Review 形式

一般来说Code Review的形式有下面两种：

• 线上

• 线下

有部分公司都会采用线上，线上的方式更符合开源社区的review的方式，大家通过线上的一些comment和reply来进行交流沟通，这样所有的review其实都有记录可查，但这样会导致一个问题，就是有人比较忙的时候可能就比较敷衍直接就进approve了。

有些公司也会采用线下，线下的方式属于集中式，学习式的review，很多时候这种模式也可以看做一次技术分享，不仅是被review的人的分享，review代码的人也可以将自己过去的经验，分享给其他同学，让大家以后都尽量避免同一个问题或者都用这种方式进行优化，并且集中式的话，大家在一个会议室精力都比较集中，review的质量也较高。但是这种有点不好的是review会占用大量的时间，如果平时本来开会就多，开发时间就少，再来几次review，那不想996也难呀。

有哪些收获？

• 提高了代码质量，知道自己的代码会被别人评审之后会写得比较认真。

• bug 数量减少，经过各个环节的评审，目的就是避免代码返工和 bug 生产，有的是带薪写 bug 哈哈。。

• 团队成员对整个项目的熟悉程度会比较均衡，代码不会只有当初的开发者了解，Code Review 后所有的参与都能修改 bug，增加新功能。

• 避免人员单点风险。

• 每个成员都可以审核别人的代码，多沟通、营造团队的技术氛围。

如果大家觉得这篇文章对你有帮助，你的关注和转发是对我最大的支持，O(∩_∩)O: