重构一词时下颇为流行，各路IDE都纷纷集成Refactor功能，VB.NET的那个Refector插件更是让人眼前一亮，不过在五彩缤纷的重构工具面前，我的想法还是思想起决定性作用，工具只是形式，更何况最有价值的重构是无法通过工具完成的。

首先，为什么要重构？
XP的一条主要原则是简单，而简单意味着代码很难始终适应业务逻辑的变更和程序规模的膨胀，重构是不可避免的。所以重构也是简单原则得以实践的重要保障。积极重构作为XP的重要教条之一，希望程序员在尽可能多的情况下去重构代码，以优化代码的质量，提高代码的可读性和可维护性。例如有些代码在开发初期并没有意识到其公用性，随着项目的进行，发现类似的功能在多处实现，XP的原则是不在最初就去揣测可能的公用方法，直到发现其公用性后再予以抽出，而且是积极地抽出。与此相比，体系架构的重构更为痛苦和繁琐，这就不是单纯能靠Refactor工具所能达成的了。这就引出了下一个问题：如何保证成功地重构？

XP提倡的积极重构由两大基础予以支撑－“勇气”和“测试”。在很多情况下，程序员面对业务逻辑重构往往充满恐惧，不仅因为重构的工作量，同时也存在着对重构之后系统是否仍能够正常工作的担忧，于是乎头痛医头，脚痛医脚，原本逻辑清晰的程序被打上重重补丁，满目疮痍。业务逻辑重构通常牵涉多个代码文件，此时千万不可被可能的重构工作量吓倒，充满勇气推翻先前的代码，并不断告诉自己，长痛不如短痛，今天的重构很有可能会避免日后更大规模的重构，优质的代码就是这样产生出来的。当然，光有心理上的勇气绝对无法造就优秀的代码，更需要技术上的保障，那便是“单元测试”。无论哪位程序员对代码做过什么样的修改，只要最终所有的单元测试都能跑通，那他/她的重构就是成功的。通过单元测试这一有力的基石，为程序员大胆重构给予了现实保障。关于单元测试，下一篇文章中予以详细说明。

XP之所以能达到比较高的代码质量，其重要原因之一便是程序员持续地重构代码，通过持续集成保证不仅代码可以正常运作，而且具有比较高的质素。不过积极重构也并不是在所有场合都适用的。首先，如果开发团队对提高代码质量没有任何兴趣，那重构对他/她们的意义就很小；另一种情况是明天就要交付一个build，完成一次迭代，此时进行重构可能会影响项目的进展，所以XP提出延迟重构，即将重构任务放到下一次迭代中完成，若重构工作量的确很大，甚至可以将重构单独列为一个任务，记如下一次的迭代计划中。

一方面希望程序员能抛开浮躁的开发心情，另一方面也希望项目管理人员、企业能更多地考虑软件的质量而不是单纯的工程周期，始终把维护成本和时间都计算在内，创造一个鼓励重构的大环境。