认识达内从这里开始

代码重构是许多程序员在解决软件问题的时候迫不得已才会选择的一种解决方法，而今天我们就通过案例分析来了解一下，程序员在什么情况下才会重构。

测试行为

重构的前提是测试优先，测试优先是XP中很重要的一项实践。对于编码来说，测试优先的过程是先写测试用例，再编写代码来完成通过测试用例(过程细节不只如此，请参看XP的相关书籍)。但是对于架构设计来说，测试行为是发生在设计之后的，即在设计模型完成后，产出相应的测试用例，然后再编码实现。这时候，测试用例就成为联系架构设计和编码活动的纽带。

另一方面，在设计进行重构时，相应的测试用例也由很大的可能性发生改变。此时往往会发生需要改变的测试代码超出普通代码的情况。避免这种情况一种做法是令你的设计模型的接口和实现相分离，并使测试用例针对接口，而不是实现。在精化和合并模式中，我们提到了一些模式，能够有助于稳定设计和测试用例。MartinFowler在他的ApplicationFacade一文中，提到使用Facade模式来分离不同的设计部分，而测试则应当针对facade来进行，其思路也是如此。

考虑一个用户转帐的用例。银行需要先对用户进行权限的审核，在审核通过之后才允许进行转帐(处于简便起见，图中忽略了对象的创建过程和调用参数)：

需要分别针对三个类编写测试用例，设计模型一旦发生变化，测试用例也将需要重新编写。再考虑下面的一种情况：

现在的设计引入了TransferFacade对象，这样我们的测试用例就可以针对TransferFacade来编写了，而转帐的业务逻辑是相对比较稳定的。使用这种测试思路的时候，要注意两点：先，这并不是说其它的类就不需要测试用例了，这种测试思路仅仅是把测试的重点放在外观类上，因为任何时候充分的测试都是不可能的。但其它类的测试也是必要的，对于外观类来说，任何一个业务方法的错误都会导致终的测试失败。其次，当外观类的测试无法达到稳定测试用例的效果时，就没有必要使用外观类了。

只针对有需要的设计进行重构

任何时候，请确保重构行为仅仅对那些有重构需要的设计。重构需要花费时间和精力，而无用的重构除了增大设计者的虚荣心之外，并不能够为软件增加价值。重构的需要来源于两点：一是需求的变更。目前的设计可能无法满足新的需求，因此需要重构。二是对设计进行改进，以得到优秀简洁的设计。除了这两种情况，我们不应该对设计模型进行重构。

使用文档记录重构的模式

应该承认，模式为设计提供了充分的灵活性。而这些设计部分往往都是模型的关键之处和难点所在，因此需要对模式进行文档化的工作，甚至在必要的时候，对这部分的设计进行培训和指导。确保你的团队能够正确的使用文档来设计、理解、扩展模式。我们在解决方案的前一个部分提到了尽可能延迟文档的创建。而在设计重构为模式的时候，我们就需要进行文档化的工作了。因为模式具有灵活性，能够抵抗一定的变更风险。

重构并保持模式的一致性

正如上一节所说的那样，模式并不是一个很容易理解的东西，虽然它保持了设计的灵活性和稳定性。对于面向对象的新手而言，模式简直就像是飞碟一样，由于缺少面向对象的设计经验，他们无法理解模式的处理思路，在实践中，我们不只一次的碰到这种情况。我们不得不重头开始教授关于模式的课程。因此，后我们在软件设计采用一定数量的模式，并确保在处理相同问题的时候使用相同的模式。这样，应用的模式就成为解决某一类的问题的标准做法，从而在一定程度上降低了学习的曲线。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。