代码质量的三点我的体会

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工具。