个人对Code Review的看法

Code Review，相信很多人、很多公司都在做。例如代码上主线的时候，需要其他成员Review代码。有些甚至是改了一行、几行代码都需要整个小组一起Review，花掉不少时间。不管是形式上的，还是真正有效的Review，至少有不少公司或者个人都认为Code Review是很重要的，也非常有意义。

本文打算从个人的角度，谈谈对Code Review的看法。一家之言，不一定讲得对，仅供参考。

曾经很长一段时间的工作，我所在的团队，基本不在乎Review这件事情的。以“测试+解决问题”作为保证代码质量的唯一手段。当时想的是只要测试用例完善，问题解决到位，那么问题解决一个就会少一个，慢慢的代码的质量就逐渐趋于稳定。所以基于这种思路，一旦代码写完了，随便测试几下，就丢给测试人员了。然后开发人员就开始悠然自得，看看资料，看看网页。

直到测试说测试出了什么BUG，然后开发人员拿到BUG，开始分析问题。一次次的复现、一次次的加日志，一次次的增加调试手段，重复很多次以后，直到一眼就看出了问题的原因。这时候一个BUG算是解决了。这种方法，其实也无可厚非，确实能够解决问题，甚至能够解决大型复杂软件的问题。只要对代码的整体逻辑有一定的理解，就这样反复的加日志、重现，即使没有彻底搞清楚代码的全部逻辑，最后基本都能搞定问题。理论上只要能够复现问题，这种方式也没什么毛病，实际上当时做的软件也最终稳定。

以前的一个同事，换了新工作，进了新公司。我们偶尔再聚餐的时候，他讲有些人遇到BUG，就是不调试，一个劲的看代码。明明调试一下，加点日志，很容易就能搞定的问题。非得花很长时间去看代码，他不太理解，觉得不可思议。然后终于通过Review看出了问题，高兴得不得了。

那么上述两种模式，一种是重测试和调试，另外一种是重Code Review。其实两种都能解决问题，各有好处。第一种，重测试+调试，这种方式能够针对问题设计调试手段，直接面对问题，反逼问题，逐渐得把问题逼到一个角落，最终解决问题。但是缺点是关注点仅仅落在问题上，对代码整体逻辑理解不深入。对于一个代码量较多的工程，比较适合。因为代码太多，一时之间也很难看懂全部代码。第二种，重Code Review，比较适合范围比较明确的问题，那么通过Code Review看出问题，有助于更深入理解代码逻辑，甚至还能发现一些潜在的问题。

对于存储软件来讲，个人觉得应该结合这两者。存储软件核心代码量并不算大，所以应该从两个方面来保障代码质量。一方面加强测试，尽可能的暴露出更多的问题。另一方面，在调试的时候，不能无脑的一顿瞎折腾，应该尽量减少反复重现的次数。一边Review代码，一边加一些必要且有效的调试手段。以这种方式来解决问题，不仅能够有效解决问题，而且对整体代码的熟悉度，在一次次的Review中，变得更加熟悉，把控度也会越来越高。

除了针对问题的Code Review，平时的例行Review也是有必要的。但是这种例行Review，因为没有目的性，不容易出效果。且因为人本身是有惰性的，说不定Review成了走马观花，抑或是欣赏自己的伟大作品，根本就找不出问题。这个就因人而异了，个人体会是这种Review要做到一个非常深入的程度才会有效果。如果只是满足于看懂了大致的逻辑，那么基本是没有用的，因为BUG基本都隐藏在细节中。这需要细致到什么程度呢，要读懂每一行代码、每一个变量各自是什么意思，有什么作用。遇到感觉不太清楚的地方，就必须要去搞清楚，搞清楚的过程就可能发现一个隐藏的问题。如果能够通过Code Review找出一些问题，这个代价相对来说是很小的。

以上是个人对Code Review的一点浅见，抛砖引玉，欢迎更多不同的意见。

-------------------------------
云和恩墨 分布式存储团队 张洋