在代码的编写中有一个很重要的环节，经常会被忽视，那就是 Code Review ,据说在 Facebook、Google 这种互联网大公司，要求每一个提交都必须通过审查，对于每个工程师来说 Code Review 是一项十分重要的工作，甚至比写代码本身更重要。

这里所说的 Code Review 是指人工的方式进行代码的检查，通常会给我们带来下面的一些好处：

• 编码风格可以保持一致，目前团队中虽然有编码规范的指引，但在代码抽查时，还是会看到很多「个性」的代码；

• 将明显问题扼杀在摇篮里，有时候存在设计上的一些错误，在后期要调整起来非常麻烦，改动大容易引发新的问题，还需要修复历史数据等；

• 新人能够快速融入团队，知道团队的编码风格，能学习到一些优秀代码的写法，也能知道哪些是禁区，不能触碰；

• 团队成员之间能够互相学习，构建良好的团队氛围。

不做 Code Review 也能完成功能的实现，只不过慢慢会带来下面的问题：

• 从每天写功能慢慢变成每天写 Bug；

• 代码的坏味道越来越浓，代码变得难以维护；

• 修改一行代码，测试没有覆盖到，往往就会带来很严重的后果；

• 可能过一段时间，就需要进行大规模的重构；

• 新人的技能得不到快速提升。

其实我们都知道 Code Review 的重要性，敏捷开发中的结对编程就包含了 Code Review ，但为什么却难以执行呢，我认为有下面一些原因：

• 项目急，时间紧，完成功能都需要加班加点，哪还有时间做 Code Review；

• 对 Code Review 的认知不足，不够重视；

• 没有相关的流程和制度进行约束，很难坚持执行下去。

我们团队的代码采用私有 GitLab 服务器，自然也使用了 GitLab 中的 MR 模式，不清楚 MR 是什么的同学可以看看我之前写的《在团队中使用 GtiLab 中的 Merge Request 工作模式》。曾经有一个美好的设想就是利用 Merge Request ，让每个人都能参与进来，在 GitLab 中进行代码的讨论，但非常遗憾，最终没能执行起来。

Code Review 的工具和方式方法非常多，我们如果能挑一两种方式，落地执行下去，就是非常好的一个开始。

上面说到 Merge Request  在团队中没有推行起来，但我个人还是在经常使用，我是代码合并的管理员之一，当合并代码时，我会重点关注两个方面：

1、核心代码的改动

• 当前功能的提交是否有必要修改到这些地方，理由是什么？

• 这些代码的改动有没有可能引发一些严重问题？

2、MR 是谁提交的

• 如果是资深开发人员提交的代码，Review 的粒度会比较粗；

• 如果是新人提交的代码，则会重点关注，包括规范以及逻辑的合理性。

除此之外，我们领导推荐的一种做法，目前在团队中一直在执行，就是写代码前先写空方法。将任何的需求转化成代码，中间的思考过程是复杂的，需要考虑很多东西：性能、扩展、是否优雅等，反倒是最终的编码实现相对是简单的。

而写空方法的过程就是思考的过程，涉及到了类的创建、抽象、组合；方法的职责，事先没有思考清楚，是写不出来的。

快速出一版空方法后，再进行沟通和讨论，找出其中有遗漏和有问题的点，进行修改，最终的版本在大方向上基本是没什么问题的。

对于 Code Review ，我自己也还在不断地探索和实践，找到适合团队的方法，执行下去，然后再持续进行改进和完善。