在代码的编写中有一个很重要的环节,经常会被忽视,那就是 Code Review ,据说在 Facebook、Google 这种互联网大公司,要求每一个提交都必须通过审查,对于每个工程师来说 Code Review 是一项十分重要的工作,甚至比写代码本身更重要。
这里所说的 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 是谁提交的
除此之外,我们领导推荐的一种做法,目前在团队中一直在执行,就是写代码前先写空方法。将任何的需求转化成代码,中间的思考过程是复杂的,需要考虑很多东西:性能、扩展、是否优雅等,反倒是最终的编码实现相对是简单的。
而写空方法的过程就是思考的过程,涉及到了类的创建、抽象、组合;方法的职责,事先没有思考清楚,是写不出来的。
快速出一版空方法后,再进行沟通和讨论,找出其中有遗漏和有问题的点,进行修改,最终的版本在大方向上基本是没什么问题的。
对于 Code Review ,我自己也还在不断地探索和实践,找到适合团队的方法,执行下去,然后再持续进行改进和完善。