第一部分：重构
　　第二部分：设计原则与代码所有权
　　第三部分：进化型设计
　　第四部分：灵活性与复杂性
　　第五部分：测试驱动开发
　　第六部分：性能与过程调优

　　设计褪色与重构

　　比尔：为什么设计会随着时间而褪色？

　　马丁：对于计划型设计来说，设计只在最开始时是正确的，随之不可避免地会褪色。生活中的许多事情都 会褪色。关键是，你要懂得如何避免设计褪色。而这恰恰是重构的目的——逆转褪色的过程。重构是一种相对来说比较新的技术。我们还未能完全掌握这项技术。不 过有一点可以肯定，你可以借助重构来防止设计褪色，甚而逆转褪色过程，使设计随着时间而变得越来越完善。

　　灵活性和复杂性

　　比尔：在《重构》一书中你写道：“在学会重构之前，我总是力图找到灵活的方案。因为设计变动的代价非常高，因而我希望我的设计能够胜任我所能预知的变化。但问题是，灵活性是有代价的。”那么，灵活性的代价是什么？有什么解决之道么？

　　马丁：灵活性的代价就是复杂性。每次当你往代码中加入一些额外的东西以提高灵活性时，通常也使你的 代码变得更加复杂。假如你的预期是对的，未来确实需要这种灵活性，那么你的超前工作得到了回报。但如果你的预期是错的，那么你所引入的复杂性将使软件变得 更加难以改动，因而该灵活性是毫无意义的。

　　而这种预期是很容易出错的。比如，当需求发生变化时，你所以为的对灵活性的需求可能随之变化甚至有可能不复存在。再比如，你添加了一些额外的代码，指望它们能提高灵活性，但这些代码本身就有问题。结果是既增加了复杂性，又未能实现灵活性，真是“赔了夫人又折兵”。

　　而解决之道就是极限编程。事实上，你根本就不需要考虑灵活性。极限编程理论认为，既然我们的预期在大多数情况下都是错的，那么就把灵活性 放在一边好了。那种冒进式的提升设计的办法是拔苗助长；平稳地改进设计才是可取之道。事实上，设计的改进是一个自我强化（self- reinforcing）的过程。如果你能够使设计尽可能简洁，避免那些无谓的灵活性，那么你所要面对的复杂性就会小很多，也就越容易对代码做出改动。代 码会更容易被读懂和被改动，你也能够更快地对软件做出调整。

　　灵活性和可重用性

　　比尔：那怎么看“可重用”呢？“灵活”是不是“可重用”的另一个代名词？

　　马丁：不，不是的。但问题是，为了使代码可重用，你必须使它灵活。很多时候，可重用性给你带来不了什么好处，或者是因为你根本就用不着它，或者是因为你所期待的可重用性与实际情况风马牛不相及。你在代码中所加入的灵活性往往并不是你最终所需要的灵活性。

　　比尔：那么，是否有些时候需要使事情变得更可重用一些？我该怎么判断呢？

　　马丁：我认为可重用也是一个逐步实现和完善的过程。起先，为了解决某些实际问题，你开发了一个应 用。接下来，你可能开发了另一个类似的应用。这时，你就可以从两个应用中提取出一些公共的片段。假如你又开发了第三个类似的应用，那么你可能提取出更多的 公共片段。在此基础上，你可能就会得到一个类似“可重用的框架”的东西。我强烈建议，不要试图一开始就定义一个可重用的框架然后在此基础上开发应用，相 反，应该是在开发过程的过程中，逐渐形成和完善框架。

　　预先设计与重构

　　比尔：你认为预先设计与重构应该各占多大比重？

　　马丁：在遇到重构之前，特别是在把重构与自动测试（automated testing）结合使用之前，我习惯于把设计看作是在开始阶段必须做好的一件事情。而现在，我认为不需要做很多的预先设计，大部分设计都是在某种进化过 程中完成的。预先设计逐渐让位于重构。比如说，在以前，我可能会倾向于80％的设计都是预先做好的，20％是在项目进程中完善的。而现在，这个比例可能要 倒过来。

　　比尔：也就是说，进化型设计的比重要比预先设计大得多。

　　马丁：没错，更多的进化型设计，更少的预先设计。