Code Review在一些公司是必要流程，在一些公司是可选流程，在另一些公司则只是名词。在工作了N年之后，分别经历过这几种类型的公司。
Code Review的好处
在过往的工作中，自己能够体会到的Code Review的作用大体有，
- 帮助统一项目编码规范
- 及时排查有误的代码设计与实现，提升整体代码质量
- 便于培训新人，加强组内互相学习，促进成员之间互相了解对方工作内容
为什么Code Review难以推广
Code Review的好处很多人都知道，参与过其中的更能明白。但工作过的同学们更应该了解，实际工作中Code Review是有多么稀缺。从个人了解到的信息来看，国外一线公司是有完备的Code Review流程的，但国内公司，不论是一线大厂还是创业公司，不论是互联网还是游戏还是传统企业，在这方面统统有所欠缺，以至于哪个公司有Code Review都是可以拿出来夸赞的。
为什么会出现这种情况呢？
首先，这是一个意识问题。国内企业少有技术主导或技术核心型公司，非技术人员很难理解这种没有直接产出的工作的意义，因此在初始的工作流程上就不会考虑增加Code Review这一流程。
其次，这是一个文化问题。国内盛行加班文化，个人认为存在加班文化的公司很难会去做Code Review这件事情。加班的目的是为了产出，或者是为了让领导看到产出，Code Review这种没有直接产出的工作很难适应这样的文化。
再次，这是一个绩效问题。Code Review不能帮助提升绩效，在周报月报上很难将此列上。有投入，无回报的事情是难以持久的。虽说Code Review能够带来多少多少好处，但具备主动学习能力的人有的是方法学到东西。
从次，这是一个效用问题。大部分代码都是业务代码，业务代码的一个现实困境就是多变。多变的需求导致代码变更频繁。很多时候做了Review，但很快整个功能就变了或被砍了，导致Review变得没有意义。
最后，这是一个成本问题。Code Review一来需要投入时间，二来需要有人来参与。很多时候某一个功能模块只有一个人负责，其它同事最多只能从代码风格上提出意见。在Review之前先去了解对应的功能需求就需要投入时间与精力，在各自都有事情去忙的时候，很难持续这么去做。这样就会导致Code Review的作用不那么明显，久而久之也就不再继续了。
另外，还有一个时间问题。这个要看项目的开发周期，以现在所处的项目举例，每周一个版本，周五出需求，周四打版本，实际可用于开发的时间只有四天。四天时间里需要理解需求、编码实现、自测、解决bug，以及再处理部分临时需求，导致完全没有精力去好好做Code Review。
推动Code Review的时机
虽然Code Review很难推广开来，不过在恰当的时机还是可以尝试去推广一下。毕竟如果处于一个学习型组织对自己的提升也是有益的，能做多少就是多少吧。
最好的时机，新人加入的时候。新人的代码通常各种问题，因此让其进行Code Review不会遇到太大阻力。如果处理得好，可以借机推广。
次好的时机，代码频繁出问题的时候。如果一段时间内整体代码质量下降，那么可以尝试去推进这件事情。毕竟Code Review对提升代码质量是有帮助的，这个时候的投入容易说服他人。
Code Review的注意事项
Code Review的第一要则，一切以代码说话，避免人身攻击。
Code Review的方式选择
Code Review有两种方式：提交前Review、提交后Review。就个人经验来看，如果要做Code Review，就选择提交前Review。
Code Review相关工具选择
直接选用常用的Code Review工具，
任何一款，真正去用了，都是能发挥作用的。
总结
Code Review对程序开发来说很重要，不过现实中很多人觉得其并非不可或缺，于是往往被省略。但实际上它是程序开发的一个必要基础设施，作为一个“专业”人士，要顺势而为推进参与其中。
在没有Code Review的技术组织中工作，对个人成长是不利的。可以分析分析导致没有Code Review的原因是什么，再来看看是否有必要继续待下去。