其实在写这篇文章之前，对code review 已经有了基本的了解，不过没有深入下去，一方面懒，一方面也是想到领导层可能并不重视，没有实践的余地。最近开会，领导首次提出了要进行code review的要求，趁此机会深入研究一下，这也是本文由来。本文概述了code review实施需要考量的问题，并未涉及技术上的细节，静待后期更新技术方面。不说废话了，马上开始。
本文内容分7个部分：
1 code review 概念
2 为什么要code review
3 code review 工作范畴
4 团队成员对code review 应该有什么样的态度
5 高效执行 code review 面临的挑战
6 实践方案
7 code review 工具推荐
第一部分：code review 概念
Code Review 是指在软件开发过程中，对源代码进行检查，提前发现bug,提高软件质量的同时提高开发人员自身水平，与正式的代码审核相比，Code Review是一种轻量级的代码评审，投入低，若能有效持续的执行，会对项目与成员起到积极的效果。
PS：Code Review虽然浪费时间，但是从长远角度看还是值得的。毕竟一开始就写好，比以后花大量时间维护与重写划算，除非负责人没打算长时间维护它，只是一次性短期的。
第二部分：为什么要code review
1.能提高代码的整体质量，提前发现bug, 换句话说决定了代码的一个质量基准（benchmark），木桶效应中的那块最短板有多高。
ps: 一个项目就像有很多窗户的房子，当有人打碎一扇窗户而没人管时，会有人打碎更多的窗户，一个项目随着时间的推移，慢慢变成了一堆垃圾，无法维护下去，只能全部重来。
2.提高了团队成员对他人代码的熟悉程度，对整个项目的现状也有清晰的认识，在需要接替任务，在同事基础上继续维护项目时，有助于快速进入感觉。
3.从成员角度看，有助于养成良好习惯，代码书写更加规范，整洁。随着习惯的养成，后期将会逐渐转化为文化与技术的交流，会对技术还是境界都有一定的提升。从团队来看，有助于形成积极的技术氛围，融洽的关系。
第三部分：code review 工作范畴
1 检查代码是否整洁，命名是否规范合理及语法问题。
ps: 多一个空格，少一个空行这种格式问题，尽量通过自动化工具完成，不要浪费他人宝贵的时间，主要是检查命名是否明白易懂
2 检查逻辑是否正确，清晰
3 检查是否有可改进的地方，更高效的方法、算法。
4 架构是否灵活，合理。
注意：code review 需要时间，精力，不要将人力资源大量浪费在基本的格式检查上，应使用自动化工具。code review应注重知识的分享，以及自动工具检测不到的问题上，让彼此成长。
第四部分：团队成员对code review 应该有什么样的态度
1 Code Review不是批斗会，评审者不能以错误、缺陷打击成员的积极性
2 作者应该以学习的态度虚心接受评审员的建议，遇到分歧可以讨论。
3 评审员职责是发现问题，跟踪改进，不是替作者修改。作者同意后应该按建议自行修改。
4 作者不要过分依赖于审核，要在提交前自己先检查，避免浪费他人的时间。
第5部分： 高效执行 code review 面临的挑战
许多事情其实并不复杂，是人的复杂性让原本的简单变得异常复杂！Code Review虽好，但是并非适合所有团队，而且执行中也会遇到诸多挑战，若是做的不好，甚至会有反效果。
下面列举一些执行中会遇到的挑战，可以评估自己的团队是否适合进行code review：
1 领导不认可，觉得没必要在这种事情上浪费时间。
此时团队成员是坚持不下去的，毕竟codereview需要时间去做，另外需要同事之间互相指出错误，对方不接受的你观点，你完全没办法。当codereview变成一件吃力不讨好的事，没有人愿意坚持。
2 团队的首要任务是快速迭代，前期的混乱可以忍受，没时间审核。
这类情况也不适合codereview。确实有些公司的功能更新太快，而且新的功能随时可能被砍掉，过早的优化都是无意义的。
3 成员刚开始会很难适应，只写了一点，结果给了十来个意见，肯定会很受挫，刚开始，提交一次，需要进行多次修改才能通过。
4 提交后审核人员一直没有进行审核，或者是提交了意见，作者一直没修改，这会严重阻碍进度，这个问题可以通过合理的制度与规划避免，不是致命的。
5 团队成员没有提高自身技能与素养的意愿。
当然大部分人还是很积极的，具有极客精神，希望更上一层楼。但是只想维持现状的人也非常多。对于倾向于维持现状的人，他们只是想按时完成老板的任务，其他的东西很难引起兴趣，也没有动力坚持下去。这对codereview的持续也是毁灭性打击，因为codereview主要是主官意愿，没有强制要求（成员懒得动或消极应付，你没辙，你没权扣他工资，更没权开了他，此时整个活动只能作罢，这种人有一个就足够了）。
6 团队中有部分成员水准太低，而有些知识素养是没办法速成的，强制code review那就是拔苗助长，适得其反。
举个例子，曾经遇到一个情况，成员中有人英语不太好，代码中大量使用汉语拼音，更让人纳闷的是他不会也懒得上网查一下，汉语拼音当变量名，方法名，可以说不能更low 了。这种情况也是非常困难的，你能一下提高他的英语水平吗？（显然不能，学校学了多少年都这样，开个玩笑，你等他学好了，项目可能已经没了。）对于这种情况，只能怪招聘的时候把关不够。当然人事有自己的考量，比如预算控制，这也不是团队成员能够控制的。
7 团队中有不少是佛系成员，codere view时得过且过。
比如codereview由团队中两个骨干负责，需要经过两个人的共同认可才行，但是其中一个骨干成员是佛系成员（别人怎么做，他都行，无所谓），这时另一位骨干提出意见就会有问题，因为别的成员会认为你这人是不是故意找茬，凑合一下不行？另一个审核员都过了，就你有意见？
身边大量存在佛系成员，这对code review是致命的。因为这样不仅不能有效与持续的执行下去，而且会导致团队成员间不和。更要命的是，所有老板希望员工和睦一团，最好安静地把事情搞好，你老是提出意见，老与同事撕，老板会觉得你这人是不是人品不行？就你不合群？你的负责，换来的是批评甚至离职。
所以最后大家都妥协了，默默的把所有问题都留着，大家相安无事，直到项目黄了，或者老板认真解决一下，然后继续恶性循环。（听着是不是有点像古代的每个王朝，大臣们都知道为什么衰落，就是不说而已，颓势不可阻挡，有那么几个忠臣说了，结果死的很惨，比干剖心，岳飞缢首）。
总结：还是那句话，是人的复杂让本来简单的事情变得异常复杂。如何通过成员间讨论设计出所有成员都认同的规则，形成所有人认同的价值观对事情的可持续发展至关重要。
不得不说前人还是当代都有不少借鉴的案例，比如抗战时期我党在军队中成立的政委制度，比如阿里巴巴网上传说的招聘闻味官，做的事情都是要将成员的精神凝聚在一起，或者提前将不具有相同价值观的人排除。github开源社区如何选择项目维护成员，让项目良性可持续发展。
第六部分：实践方案
1 通过成员间讨论，确定所有人认可的代码规范，git使用规范，代码审核原则。
2 确定审核人员，方式很多，下面列举几种：
2.1 至少有一名经验较他人丰富的骨干成员当主审，以及不限数量的其他成员作为可选审核员。代码通过需要至少一个主审同意，所有审核员都可以对代码发表意见。
2.2 直接由技术leader或小组leader审核。
2.3 结对编程，团队中每两个人组成一队。互相审核，每天就是互怼。一段时间后交换伙伴。知乎上看到, thoughtworks采用结对模式，一个人写一个看你写。一个叫做导航者，一个叫做司机。随时发问，你这个地方写的不好，应该怎么样。不过这样感觉很耗人力的，两人变成一人了。
ps: 个人比较倾向于第一种方法。
3 确定审核时机
提交后需要及时审核，否则会耽误作者时间。但是审核员也有其他事情，不能随时马上执行。
提交的代码量不要太大，不要堆积几天甚至一周的代码，这对审核员来说工作量太大，而且一次修改很多问题也让人很受挫折。
个人认为比较好的解决办法是每天集中在一个时间段审核，比如下午5点开始，成员需要在5点之前提交一天的代码，然后由其他成员开始审核，讨论，并修改。
当然在若有急需的审核，也可马上进行，规矩并非一成不变。
4 激励机制
对code review 中积极帮助他人，分享大量知识，及时发现重大bug的成员进行奖励。
奖励方式很多，包括但不限下面这些：
1 现金奖励
2 休假奖励
3 提升项目管理权限
等等。。。。。。
第七部分：code review 工具推荐
GitLab
GitLab,GitHub这些仓库托管平台如今也具有code review 功能，基本可以满足需求。
Gerrit
比较流行的code review 工具，是谷歌用来管理Android项目的工具。
SonarQube
代码质量管理平台，具有完善的功能，适合对代码质量要求很高的团队。