codereview怎么再次提交（关于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，增加新功能。
• 避免人员单点风险。
• 每个成员都可以审核别人的代码，多沟通、营造团队的技术氛围。 本文由博客群发一文多发等运营工具平台 OpenWrite 发布