关于 CodeReview 的一些思考

背景





上图为[产品迭代开发协作流程]，其中我们在 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 是一次代码提交请求，提交后，其他工程师可以在这次请求中提出修改建议，也可以针对某一些代码的发动进行讨论或是整体的评价。



gitflow 工作流程



Code Review 形式(公众号：咖啡拿铁 补充内容)



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



• 线上

• 线下



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



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



有哪些收获？



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

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

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

• 避免人员单点风险。

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



更多内容请关注：https://yezhwi.github.io/