和敏捷方法的教条主义者相比，我在软件设计和实现之初，不会寄望于将来的重构；而当重构真正需要发生的时候，我也会坦然面对。 按照Martin Fowler的定义，重构是指在不改变行为的情况下改变代码的内部结构。可是，在现实中，需要重构的何止是代码的内部结构，而往往是程序的整体结构。这种现象是违背敏捷思想的。在敏捷开发者看来，如果持续进行重构，就会避免严重的缺陷。

尽管如此，但现实总是另一个样子。 我曾经遇到过大连小程序软件开发的一个公司：因为历史遗留的原因，这个系统开放了几千个没有进行任何控制的API。这些API之间，业务上自相矛盾、实现上高度耦合，甚至有大量的冗余。更要命的是，这些API已经被广泛使用。在这种情况下，要保留代码的外部行为是无法进行重构的。这样的系统首先要在业务层面上进行重构。 影响重构持续进行的因素有很多，其中最大的未知因素在于人。尽管敏捷方法提出了很多好的实践，但是由于大连小程序软件开发人员技术能力上的差异以及团队中复杂的社会性，很多实践都流于表面，比方说，在实施敏捷方法时，只是专注于形式化的例会、口号化的积极创新、保守的迭代目标等。

所以，重构的要求总是发生在问题爆发的时候，例如无法忍受的性能问题、漏洞百出的安全问题。在此之前，代码重构（表面上看不到成绩，而主动性要求极高的活动）往往被忽视。忽视的结果就是产生“伪敏捷”，道理很简单：没有进行代码重构，一切都是空谈。 站在现实的角度上，无论你是否承认大连小程序软件开发公司的实力如何，重构总是和系统级别的程序结构联系在一起。对于这样的重构，业务接口都无法保持不变（业务功能保持不变）。也许我们应该把这种重构称为“再设计”。 好在我们还有一些选择，例如，SOA、组件化。 SOA可以抽取现有系统中有价值的业务接口（如果有的话），可以开放出一组更加合理的新接口，从而实现对程序结构的再组织。

组件化则是从系统内部开始来重新组织系统的程序结构。客户管理软件在开发过程中不可避免的一些问题，这的确是再设计的过程。我们会在以后的章节中讨论这个话题。 从重构的目的出发，我更倾向于组件化的方式。组件化可以让程序结构（实现同样的业务功能）焕发青春，这种改变是由内而外的，就像植入了一种好的基因。