不知道你有没有遇到这样的场景，刚上线的一个功能，就出现了一个严重Bug，团队周末集体加班吭哧吭哧的紧急处理，你们彼此抱怨不断；你和老板在给客户演示产品新功能的的时候，突然系统崩溃了，在场的人一阵尴尬，急忙解释一阵说这一块还没处理好。
遇到这种问题怎么办？是每个人只负责其中一个模块么，遇到问题出现问题的人处理吗？不行，这样忙的同学会忙死，闲的同学没事儿做；那招一个测试同学呢？也不行，我们并没有招聘的预算；
其实解决这个问题就是做好代码质量管理，而代码质量管理最重要的方法就是「Code Review」也就是代码审查，为了简单，下文我用CR简写。
代码审查在维基百科解释：
指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。
简单来说CR就是通过审查代码来提升软件质量和开发者技巧的方式。
为什么要做 Code Review
那么为什么说CR能够提升软件质量和开发者技巧呢？以及为什么我们要做CR？
首先对于初学者，CR是一种很好的学习方式，因为负责主要审查的人往往具有更丰富的经验，知道哪些位置有坑，哪些写法会造成问题，这样可以最大限度的从代码过程中提升个人技能。
尤其是那些资深的同事给新人进行指导讲解的时候，效果可能不仅仅是知识代码层面的，更是对以后工作态度，学习求真的深远影响。要知道工作态度比知识和技能在工作中的影响占比大的多。
记得我刚实习那会儿，就得到过公司技术VP余弦大佬指点，工作中身边的同事也对我的代码进行了比较严格的审阅，那种一行一行的进行矫正，真是酸爽，那个时候能明显感到自己在进步。
其次对于资深开发者，通过CR这种方式，自己能发现原来这种错误也容易出现啊，自己也需要注意下，避免掉坑。
另外有些开发过程有些功能自己使用的方法也不一定做到最好，有同事提出他的意见想法或者技巧时，你们就能碰撞出思维的火花，相互受益。
最后CR更好的利用了人性，就是更能发现别人的问题，这种相互的方式就能大大降低问题故障点。据统计正式的代码审查发现缺陷率 60~65%，非正式不到50%，但也能发现很多问题。
通过这种方式我们在不断交流讨论过程中不仅提升了开发技巧更重要的是软件质量也得到了保证。
怎么做Code Review
说完了，CR是什么（what），为什么（why）要去做CR，先我们来聊聊怎么做（how）CR。
通常情况主要是按照Github的Pull Request发起请求合并代码的方式，通过指向某一个或多个负责合并的人来进行。
代码审查一般会分为三类：正式的代码审查、结对编程、以及轻量型的非正式代码审查。
我们来看gitlab官方示例图:
上面这个图主要说了这个请求提交做了什么事儿，我们的集成测试通过与否。
这里面主要看到了我们代码的变更情况，方便做代码审查的人来进行阅读。
我来说一个简单的CR步骤流程：
1. 保证所有的单元测试和持续集成跑过，你这个提交做了什么事（避免浪费别人理解时间） 2. 这个代码至少有两个及以上的团队成员意见通过并且评论回复LGTM（回复任意的都行，有chrome插件可以检测这个数量） 3. 最终进行合并代码入库（可以指定固定人合并也可以不指定）
解释一下第二个步奏，保证有多人进行查看审阅，不仅可以保证代码质量，并且可以保证不会出现单点的情况，比如你请假至少有同事熟悉你写的代码。这也是我们所说的高可用。
在做CR的过程中我们需要注意：
- 对代码不对人，很多时候需要注意沟通的艺术，尤其是异步沟通的时候。
- 尽量统一风格，不过于纠结风格，保持宽容态度
保证这两点我们就能开心愉快的讨论技术问题，顺便提高了软件质量。
小结
本文最后让我们来回顾一下文章的主要内容。
首先我们通过一个严重bug和系统崩溃引出了解决这两个质量问题的方法--Code Review（代码审查）。
然后我们解释了Code Review可以提升代码质量和团队技能，利用好了这种方式及人性的特点，不仅对新手帮助巨大，也能帮助经验丰富的老司机。
最后我们简单说了Code Review的流程以及做这个过程注意点。
