重构：确保加入新功能后代码仍保持简单，从而保证简单的代码仍然能够运行所有的测试。
作为新员工，入职后的很长一段时间都是在阅读“前辈”们的设计文档和程序代码，在维护以前的项目。这原本是最快捷的学习过程，然而不幸的是我们常常看到的是与实物不一致的设计文档和纷乱、繁杂的代码。代码中的变量常常不知所谓，定义的变量、方法不知道在哪里调用，不知道什么作用。偶尔看到的注释却发现除了里面除了注释是谁增加的，却不知道对应的是哪些修改的代码……越看越糊涂，怎么办？干脆自己重新写一个吧！
我在处理入库的代码时询问提交人某个目录里面的代码有什么用时，得到的答案却往往是“不知道”。生命周期越长的程序，里面的目录和文件越是繁杂，从名称上很难看出文件之间是什么关系，类似以test这样的无意义的名称命名的文件随处可见。
关于重构，是一个相对复杂的话题，通常按照对一个问题的考虑思路是这样这样论述的：重构是什么？为什么要重构？怎么重构？
有本书名字叫《重构——改善既有代码的设计》，专门论述重构，我想自己再怎么写也不可能好过它了，所以推荐大家去看书吧。下面还是为大家说一下当年我们软件开发团队中的一些做法（和测试原则一样，在没有接触到敏捷开发之前我们就已经有意识的在某些方面做一些改进了）：定期进行代码检查，增强代码的复用性
代码复用性的提高势必会加快整个软件开发速度，而代码复用性的提高对开发效率有着最大的积极影响，但是它也能产生最大的消极影响。重复使用的积极影响和消极影响的关键差别可以只用一个词概括，那就是“质量”。如果重复使用的程序达到零缺陷，那么重复使用会产生积极影响。如果重复使用的程序充满了缺陷和错误，那么开发效率会大大降低。我们现在的开发很大程度上是在copy。这不是说我们的工作没有创造性，反而对我们的代码质量提出了更高的要求。
软件检查提高开发效率的同时改进质量，测试一旦开始，有很多缺陷的软件不会被允许交货。问题太多的软件会延长测试过程，同时加大测试成本直到超过项目预算的一半。
对软件开发来讲，设计和代码的预防性检查打下了牢固的质量基础，同时加快测试过程并减少问题的出现。
下面总结了最常见的方法：
1、走查
最平常的回顾可能是非正式的走查了。是指任何两个以上的开发人员以增进软件质量为目的所召开的回顾技术工作会议。走查对于快速开发很有用，因为这样可以在测试前就发现漏洞。举例来讲，测试能够发现需求漏洞的最早实践是需求刚被列入清单、设计和编写的时候。走查可以在写设计说明书时，在设计和编写完成之前就发现漏洞。走查可以发现30%到70%的程序漏洞。
2、代码阅读
代码阅读是比走查更正式些的回顾方式，但仅适用于代码。代码阅读中，写这段代码的程序员把代码清单交给两个或更多的审阅者审阅。审阅者阅读代码并把发现的错误报告给作者。代码阅读能发现的漏洞是测试时能发现漏洞的两倍。这意味着，在快速软件开发时，将代码阅读和测试结合在一起，会比仅仅测试在时间进度上更具有效率。其实，作为新员工在阅读前辈的代码时，一边阅读，一边试着按照自己的理解去做一些修改，看看结果是否和自己想得一致的做法从某种意义上来讲就是重构。
3、检查
检查是一种正式的技术回顾，他被认为是在整个项目中最具有效率的差错方式。使用检查的方法，开发人员要接受关于检查的特殊训练，并且在检查中扮演重要的角色。在检查会议之前，“仲裁人”发布产品要被检验估算的消息。“审阅人”在会议前检查程序，并且用检查列表激励他们的回顾工作。在检查会议上，“作者”通常要解释要检验的东西，“审阅人”鉴别错误，“书记员”纪录错误。在会后，仲裁人写一份报告说明每个漏洞和该如何处理它。贯穿整个检查过程，你需要收集漏洞的数据，花一些时间改正漏洞，花一些时间再进行检查，以便你可以分析软件开发进程的效率并不断改进它
和走查一样，你可以使用检查的方法比测试先一步发现漏洞。你可以在项目中使用它对需求分析、用户界面原型、设计、编码以及其他人为的过程查错。检查可以查出程序中60%到90%的漏洞，这点要比走查或测试要要。因为可以在开发周期的早期应用，因此，检查方法被证明可以节约10%到30%的开发时间。一项对大型程序的调查结果显示，在检查上每花1小时，可以避免在维护中33小时的花费。检查比测试有效20倍以上。
来自：http://blog.csdn.net/blueluhan/archive/2008/08/08/2787247.aspx