code review

Code Review 的重要性

接下来说的都是以你在 github 上合作写代码为例

为什么要 review

bug 越早发现,它所带来的时间成本和经济成本上的损失越小,当然最好的状况是写的代码少点 bug。你 review 时可能花十分钟就可能会发现的问题,以后在生产环境上你需要花多少时间来定位呢?虽然代码审阅看起来好像需要很多时间成本, 但是实际上带来的收益在我看来是十分值得的。bug 一堆的代码看起来好像是完成了需求,实现了功能,但在今后的实际运营中, 却需要花费更多的时间去解决。稳健的逐步行走,可以走得更远,走得更好,走得“更快”。

一个庞大的系统肯定是由多个工程师一起合作完成的。设想你发现了一个 API 的问题,这个 API 是由小明写的,审阅你提的 PR 的时候,就要叫上小明。一方面来说,这个 API 是小明写的,虽然你可能改了一个地方,但是它其实牵扯到相当多的模块, 背后有更加复杂的逻辑,就像你可能只是看到冰山一角,原作者肯定有比你知道得多的 context,叫上原作者来看看你的修改是否真的解决了问题。 但是,我认为这样还不够,你也许应该叫上其他的相关人员。他们或许只是看一下,但是这就够了。及时的让同事知道你的修改, 让大家都知道这个修改,而不是以后写着写着突然发现,啊,这个逻辑什么时候被改的呀,还要 blame 一下,翻记录才知道。

新同事的代码让师傅审阅,讲解系统的实现细节,还能指出更好的实现和抽象,帮助新同事更快得上手。同时,审阅时的相互之间的交流, 本身就是对双方的提升。

如何 review

一般都是提交 PR,但是怎么提,我说说我的想法:

一个 1000 行的修改,review 起来不仅花时间,而且效果不好甚至没有效果。小粒度并且有主题的修改,不仅有针对性,review 起来也方便省时,效果也好。

小粒度的 PR 还有一个好处。相互之间的影响会小点。如果你的 PR 很大,别的同事要基于你的代码开发,那大家怎么办呢, 代码推到你的分支的话结果这个 PR 又变得很大了。。。

不仅如此,我还建议写写你这个 PR 主要针对的问题, 你怎么解决,review 的注意细节等等。举个例子:

## 本次 PR 内容

* 修复了某某某问题, 原因是 xxx,现在改成使用 xxx
* 针对以上问题同时增加了对应的测试。

review 注意细节:

* xxx 这里的逻辑感觉实现不是很好,有更好的方法可以说说。

当然这个并不是模板,核心思想就是说明你的 PR,让 review 的同事可以更好更快理解,同时留下你的想法和开发记录, 以后出了问题也许还可以知道当初是怎么想的。