据说有一位程序员，写了6000多行的汇编代码，自己Review了近100遍，最后到测试的时候没有发现一个bug，后来这件事被公司树为样板。
对于这件事有几点不合理的地方，首先，代码行数并不能体现软件的复杂度，相同长度的代码，逻辑复杂的写起来肯定要难些，这无需多说。其次，使用代码行数这个指标隐含的意思就是不鼓励代码复用。你可以在多处写相同的代码来扩充代码规模，而并不在乎软件的可维护性，可重用性等等。这样就使得使用代码复用的程序员看起来也不比那些能写超多代码的人工作得更出色。
我们可以列举许多的理由来说明这件事很荒谬，但是难道从中就没有可以学习的地方吗？
我们对设计，编码，测试这些话题说得很多很多，但是却往往忽视了Review这项活动，Review不重要吗？当然重要，软件开发过程中的活动没有一项不重要的，但是Review一般情况下时间没有其他阶段多，而且作用似乎也不那么明显，所以常常流于形式，一带而过，也就是走个过场而已，并没有发挥它应有的作用。
但是在实际的开发中，有很多代码在提交测试前，都包含着一些明显的bug，这些bug一般不严重，甚至有很多都是细枝末节上的问题，但是由于数量多，所以对代码的质量还是有较明显的影响。而这些问题中又有很多是不需要运行起来看到效果，单是通过代码阅读就能发现的。
我们可以看看结对编程，在结对编程中所包含的一个很重要的实践就是Review，一个人写代码，另一个人看，任何一句代码在写下时就进行了Review，如果发现了问题会马上被指出，修正。这样时时刻刻的Review可能是所有Review方式中最频繁的。这样真正留给测试可发现的bug就少了很多，代码的质量也会有大的提升。
如果在你的开发活动中没有Review，更没有结对编程，那么可以在代码完成后自己进行Review，不要100遍，只要两遍，相信你就会感受到它的作用。我自己就经常在Review自己的代码时发现在眼皮低下一次次的跑过的bug。
Review100遍？实在是个疯狂至变态的举动。“Review100遍！”，提醒自己认真对待每件事，你的细心与认真会带来丰厚的回报。
