代码质量的三点我的体会

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工具。
相关文章
相关标签/搜索