聊聊Code Review

   大家都经常讨论到CodeReview（以下简称CR），但是很多时候我们并不知道我们为何要去做CR，而是按照公司的相关制度规定执行。所以，我在这里先抛出一些问题：CodeReview到底能给团队带来什么？什么样的团队需要进行CodeReview活动？如何有效开展CodeReview活动？用哪种方式会比较好呢？

CodeReview到底能给团队带来什么？

在一次开发团队的内部分享会中，我问了大家这个问题，我初步的总结了一下：
1、促进工程师日常代码交流和人员的成长；
2、团队营造浓厚的工程师交流氛围；
3、为产品质量进行把关等；

适合什么样的团队？

1、对技术追求高，技术驱动型的团队；
2、服务的范围广，涉及面也非常重要，出现质量问题影响严重的，对质量要求很高的团队；
3、测试人员缺失，或者测试环境比较弱的团队；
4、新人密集的团队；
5、任何有主动意愿的团队；

不适合什么样的团队？

1、疲于应付的团队，项目节奏非常紧，每天淹没在需求的沟通以及变更 优化；
2、创新型的团队，需要快速的开发出产品投入市场进行验证，更加倾向与敏捷的开发；
3、领导或者核心技术骨干不认同Code Review的意义的团队；

如何进行CodeReview？

要想在团队内部有效运作CodeReview活动，必备四要素。
1、代码规范：参考《阿里巴巴集团java开发规范》，附加项目个性化的规范，经过领导和团队的评审进行发版，形成团中的标杆，衡量好坏的依据；

2、检视指南：也就是CodeReview-Checklist，checklist有必要指出团队中非常关注的几个重要的点（性能效率、内存泄漏、死循环、异常处理等等），不求完全覆盖所有的检查项，对于核心要素必须指明，作为团队互相进行CodeReview的审查依据，并进行不断的更新；

3、总结优化：团队需要对每周的Codereview进行回顾、总结分析，持续优化，推进团队的运作，而不是指停留于形式，要找问题的本质，对于有代表性的问题，需要在每周的分享会中进行分享---这一项任务的前提是建立CodeReview的记录机制，考虑如何进行记录的整合和存档；

4、激励机制：激发团队的主观能动性，可以考虑与团队人员的绩效考核挂钩（人员评级），或者针对CodeReview记录表，评估一周质量之星或者按月（奖励书籍、徽章等）；

CodeReview形式： 推荐强制+事前+小片段+线上交流+高频率

根据项目的实际情况，我总结了以下几点：

1、前期进行执行强制性，培养开发人员的习惯，后期再逐渐放宽；
2、对于新项目，提交的内容必定是比较新，无法实现小片段高频率的评审，建议采用每周按照功能块的评审；
对于运维项目，尽量使用小片段的对比评审；
3、事前评审，即发布前进行CodeReview，控制产品的质量，减少验收时的返工率；
4、线下频率：每周1_{2次，每次1}2小时；线上：每天，固定30~45分钟；
5、项目开发小组长即Gitlab中Group的master；