来源：r6d.cn/NzDTjava
众所周知，Code Review是开发过程当中一个很是重要的环节，可是不少公司或者团队是没有这一环节的，今天笔者结合本身所在团队，浅谈Code Review的价值及如何实施。web
1. Code Review的价值
许多团队没有Code Review环节，或者由于追求项目快速上线，认为CR浪费时间；或者团队成员缺乏CR观念，认为CR的价值并不大。因此想要推进CR在团队中的实施，最最重要的一点即是加强团队成员对CR环节的认同感。api
Code Review环节，它更加依赖于团队成员的主观能动性，只有团队成员对其承认，他们才会积极地参入这一环节，CR的价值才能最大化的体现。若是团队成员不承认CR，即便强制设置了CR流程，也是形同虚设，反而可能阻碍正常开发流程的效率。那么如何让团队成员承认CR环节呢，天然是让他们意识到CR的价值，而后就会……真香！
微信
1.1 提高团队代码质量
随着团队规模的扩大和项目的迭代升级，团队之间的信息透明度会愈来愈低，项目的可维护性也会愈来愈差，可能引起以下一系列问题：app
已有的utils方法，重复造轮子编辑器
代码过于复杂，缺乏必要注释，后人难以维护学习
目录结构五花八门，杂乱不堪测试
……
合理的CR环节，能够有效地把控每次提交的代码质量，不至于让项目的可维护性随着版本迭代和时间推移变得太差，这也是CR的首要目的。CR环节并不会下降开发效率，就一次代码提交来讲，也许部分人认为CR可能花费了时间，可是有效的CR给后人扩展和维护时所节省的时间是远超于此的。优化
1.2 团队技术交流
Reviewer和Reviewee，在参与CR的过程当中，都是能够收获到许多知识，进行技术交流的。ui
有利于帮助新人快速成长，团队有新人加入时（如实习生和校招生），每每须要觉得导师带领一段时间，经过CR环节，可使导师最直接的了解到新人开发过程当中所遇到的问题，做出相应的指导。
经过CR环节，团队成员能够了解他人的业务，而不局限于本身的所负责的业务范围。项目发现问题时，能够迅速定位到相关业务的负责人进行修改。同时如有的团队成员离职后，也能够减小业务一人负责所带来的后期维护困难。
学习他人的优秀代码。经过CR环节，能够迅速接触到团队成员在项目中解决某些问题的优秀代码，或者使用的一些你所未接触过的一些api等。
1.3 保证项目的统一规范
既然要进行CR，首先要对项目的规范制定要求，包括编码风格规范、目录结构规范、业务规范等等。一方面，统一的项目规范才能保证项目的代码质量，提升项目的质量和可维护性；另外一方面，在你们熟悉了统一的规范后，可以提高CR的效率，节省时间。
2. Code Review的实践
关于Code Review的实践，要考虑的包括CR所花费的时间、CR的形式、什么时候进行CR等等。
2.1 预留CR的时间
首先不得不认可，CR环节是要耗费必定时间的，因此在项目排期中，不只要考虑开发、联调、提测、改bug等时间，还要预留出CR的时间。包括担任Reviewer和Reviewee角色的时间都要考虑。
另外若是遇到的需求比较复杂，为了不由于CR过程致使代码须要大量修改，最好提早和团队成员沟通好需求的设计和结果思路。
2.2 CR的形式
我所见过的CR大多有两种形式。一种是设立一个特定时间，例如每周或者每半月等等，团队成员一块儿对以前的Merge Request进行CR；另外一种是对每次的Merge Request都进行CR。
我我的更偏向于后者。第一种按期CR，Merge Request的数量太多，不太可能对全部的MR进行CR，若是CR以后再对以前的诸多MR进行修改为本太大；并且一次性太多的CR会打击团队成员的积极性。第二种MR相对就轻松的多，能够考虑轮班天天设置2-3人对当天的MR进行CR便可。
2.3 CR的时机
CR的环节应该设立在提测环节以前。由于CR后若是优化代码虽然理论上只是代码优化，但极可能会对业务逻辑产生影响，若是在提测时候，那么可能会影响到已经测试过的功能点。
固然也要分状况，若是遇到比较紧急的需求或者bug修复，那么也能够先提测，后续再作相应的CR。
3. 对团队成员要求
前面已经提到，要加强团队成员对CR环节的认同感。做为CR环节的参与者，还应该根据本身的团队特色，对团队成员作出相应要求，能够参考咱们团队。
3.1 Reviewer
指明review的级别。reviewer再给相应的代码添加评论时，建议指明评论的级别，能够在评论前用[]做出标识，例如：
[request]xxxxxxx 此条评论的代码必须修改才能予以经过
[advise]xxxxxxxx 此条评论的代码建议修改，但不修改也能够经过
[question]xxxxxx 此条评论的代码有疑问，需reviewee进一步解释
讲明该评论的缘由。在对代码作出评论时，应当解释清楚缘由，若是本身有现成的更好地解决思路，应该把相应的解决思路也评论上，节省reviewee的修改时间。
平等友善的评论。评论者在review的过程当中，目的是提高项目代码质量，而不是抨击别人，质疑别人的能力，应该保持平等友善的语气。
享受Code Review。只有积极的参与CR，把CR做为一种享受，才能将CR的价值最大化的体现。
3.2 Reviewee
注重注释。对于复杂代码写明相应注释，在进行commit时也应简明的写清楚背景，帮助reviewer理解，提升review的效率。
保持乐观的心态接受别人的review。团队成员的review不是对你的批判，而是帮助你的提高，因此要尊重别人的review，若是review你感受不正确，能够在下面提出疑问，进一步解释。
完成相应review的修改应当在下面及时进行回复，保持信息同步。
本文分享自微信公众号 - 肥朝（feichao_java）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。