家喻户晓，Code Review是开发过程中一个十分重要的环节，然而很多公司或者团队是没有这一环节的，明天笔者联合本人所在团队，浅谈Code Review的价值及如何施行。
1. Code Review的价值
许多团队没有Code Review环节，或者因为谋求我的项目疾速上线，认为CR浪费时间；或者团队成员短少CR观点，认为CR的价值并不大。所以想要推动CR在团队中的施行，最最重要的一点便是加强团队成员对CR环节的认同感。
Code Review环节，它更加依赖于团队成员的主观能动性，只有团队成员对其认可，他们才会踊跃地参入这一环节，CR的价值能力最大化的体现。如果团队成员不认可CR，即便强制设置了CR流程，也是形同虚设，反而可能妨碍失常开发流程的效率。那么如何让团队成员认可CR环节呢，天然是让他们意识到CR的价值，而后就会……真香！
1.1 晋升团队代码品质
随着团队规模的扩充和我的项目的迭代降级，团队之间的信息透明度会越来越低，我的项目的可维护性也会越来越差，可能引发如下一系列问题：
- 已有的utils办法，反复造轮子
- 代码过于简单，短少必要正文，前人难以保护
- 目录构造形形色色，杂乱不堪
……
正当的CR环节，能够无效地把控每次提交的代码品质，不至于让我的项目的可维护性随着版本迭代和时间推移变得太差，这也是CR的首要目标。
CR环节并不会升高开发效率，就一次代码提交来说，兴许局部人认为CR可能破费了工夫，然而无效的CR给前人扩大和保护时所节俭的工夫是远超于此的。
1.2 团队技术交换
Reviewer和Reviewee，在参加CR的过程中，都是能够播种到许多常识，进行技术交换的。
- 有利于帮忙新人疾速成长，团队有新人退出时（如实习生和校招生），往往须要认为导师率领一段时间，通过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的批改该当在上面及时进行回复，放弃信息同步。