代码质量的三点个人体会

Martin Fowler在他的著作《重构，改善既有代码的设计》的第一章说过“任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。”
   Kent Beck也这么形容过自己“我不是个伟大的程序员，我只是个有一些优秀习惯的好程序员。”
   自己从本科阶段到现在也大概写了三年多代码了，再加上7个月的实习和3个多月的工作时间，也慢慢体会到编程不易，而要写出高可读性和少缺陷的代码更不易。
   虽说“软件工程没有银弹”，但也有一些方法可以予以弥补。方法即Kent Beck所说的培养一些优秀的编程习惯。
   我个人写一些代码时总以为代码很简单，功能逻辑都很简单，所以总是全部写完，然后再跑，但90%的情况跑的结果都让我失望。一次次打击之后让我开始的信心满满逐渐无存，自己也开始尝试理性思考如何编程才能保证效率同时提高代码质量（代码可读性强、缺陷率低...）。
   以下是我的三点个人体会：
   第一点：Code Review，而且注意是在每写完一段代码就马上Review。
   比如一个方法就十几行代码那么可以写完这个方法然后Review，Review时审查代码分支，相当于人脑编译运行。而如果一个方法很长，那么可以将方法拆成几块，每写完一块Review一下。这样能规避很多我们看来比较弱智的错误。比如我在编写返回布尔值的代码时经常先让返回值直接为false。如下：

public boolean test() {   // TODO
   return false;
}

   然后继续完成TODO部分代码：

public boolean test() {   // 一大段处理逻辑
   return false;
}

   这样写完之后我马上在其他地方调用test()，但发现test方法始终返回false。我百思不得其解，只好单步调试，才发现我犯了一个很弱智的问题，你懂的。而如果我写完这个代码后不急着运行程序，而是先静态Review下代码，这种低级错误是完全可以避免的。   
   第二点：重构，而且是持续重构。
   一直以来我只是人云亦云地认为重构对提高代码质量很有帮助，但实际上一直对重构没有什么概念，也一直没有在实际编码中真正践行过多少。但我试着真正动手去重构了两个例子后，才发现重构确实威力强大，它可以提高代码可读性，并加深你对代码业务逻辑的理解，也因此减少了引入Bug的机率。重构只要使用得当，还可以在代码简洁性和代码可读性之间取得不错的平衡，具体例子请参考：
   编程基础问题探讨：代码可读性与代码简洁性的权衡 http://www.oschina.net/code/snippet_111708_15532
   编程基础问题探讨：双重循环写法 http://www.oschina.net/code/snippet_111708_15531

   第三点：测试驱动。
   有时候我从前台页面到后台业务处理，写完几百行代码然后运行，出了点小问题，然后单步追踪，Fix掉。再跑，没问题，OK发布，提测。然后测试一测，各种问题接二连三地又回到我手里。想了很久，最后发现测试驱动应该是避免我这种困境的较好方法了。按照我之前的“撞大运”式编程，我只能保证某一个或有限的几个流程（或分支）运行正确，实际上代码中还是可能存在不少“定时炸弹”。而借助测试驱动开发方法，我可以每写一块就测试一块，确保每一块都是正确的，这样之后再集成测试显然能好不少。而且要知道Fix Bug的时间经常比写代码的时间要多很多，尤其是在系统运行很长一段时间后才发现Bug（这时已经对系统不是那么熟悉了）或由非代码第一作者Fix Bug时表现更为明显。

   常见的单元测试工具包括针对Java的JUnit，针对C#的NUnit和VS 2010以上版本自带的Unit Testing工具。