你有做 Code Review 吗？

在代码的编写中有一个很重要的环节，经常会被忽视，那就是 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、核心代码的改动