本次访谈分为六个部分。在第一部分，福勒探讨了重构和测试在开发过程中扮演的角色，并描述了重构、设计、以及可靠性之间的相互作用。

　　——引子：中国软件业所缺少的，不是士兵，而是军官，不是新兵训练营，而是黄埔军校。

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

　　第一部分：重构

　　在过去十年中，马丁·福勒在商业化信息系统开发领域倡导了许多新的软件开发技术。他在许多领域的工作都为世人所瞩目，包括：面向对象的分 析与设计，软件模式，统一建模语言，敏捷软件开发（特别是极限编程），以及重构。著名的出版社艾迪森维斯理（Addison Wesley）曾出版过若干本他的著作，如《分析模式》（1996年10月），《重构》（1999年6月，与肯特·贝克合著），《UML精粹》（1999 年8月，与肯德尔·斯考特合著），《规划极限编程》（2000年10月，与肯特·贝克合著），以及即将出版的《企业级应用架构模式》（2002年11 月）。

　　这次采访分为六个部分。福勒谈到了他对许多话题的看法，包括重构，设计，测试，和极限编程。在第一部分，福勒探讨了重构和测试在开发过程中扮演的角色，并描述了重构、设计、以及可靠性之间的相互作用。

　　比尔：请给出重构的定义。

　　马丁：重构就是对代码本身做出修改，以改善它的内部结构，但又不改变它的外部表现。

　　比尔：如果重构既不添加新的功能也不消除已有的漏洞，那它的商业目的是什么？你是怎么看待重构的？

　　马丁：重构改善了设计。而一个良好的设计，其商业目的何在？我认为，它使你能在未来更容易地对软件作出改动。

　　重构实际上是在说，“来吧，让我们把系统结构重新调整一下，好让将来的任何改动都更容易些。”其潜台词是，如果你不会改动你的系统，那么也 就没有必要做重构，因为不会有任何回报。但如果你将要对你的系统作出改动——不管是消除漏洞也好，还是添加新功能也好——那么，一个好的或更好的系统结 构，会使你在做修改时有所受益。

　　重构与团队

　　比尔：一个团队中，各人有各人的编程习惯。我的一个朋友在一家公司做事，公司进了个新人，那个人对于什么是好的命名规则有自 己的一套想法：他喜欢在成员名字的前面加上“m_”前缀、在词与词之间加上下划线，等等。于是他做了一些简单的重构，就像你推荐的那样，但这些重构造成了 一些问题。

　　比如，由于授权许可的限制，公司的一些代码是保密的，这个新人无权访问。结果他的重构造成了代码不一致，我的朋友不得不修补这个问题。而 当我的朋友需要修补在多个版本中都存在的漏洞时，问题又来了：重构导致了在不同的版本中命名规则是不一样的，这无疑给不同版本的漏洞修补工作增添了难度。 此外，公司里像我朋友那样的旧员工，已经习惯了旧的命名规则。有一次，我的朋友怎么也找不到一个方法函数，因为它的名字被改了。诸如此类的问题，都是因为 那个新人所做的重构。

　　那么，在一个团队里，应该由谁来决定命名规则？又应该由谁来决定何时以及如何做重构？

　　马丁：重构并非让你变态地去重命名一大堆东西，而理由仅仅是你觉得那样好。重构必须要有收益。假设你在做重命名，那么你应 该查找那些名字和意义不符的方法，并且其他使用该方法的人也觉得应该改名才行。说到命名规则，一个团队必须要有一个都能接受的命名规则。如果你是新加入 的，那你必须了解这套命名规则。假设我作为一个咨询师进入团队，那我不会把我的命名规则强加给团队。我会询问团队的命名规则是什么，熟悉它们，使用它们。 当然，从另一方面说，我坚决反对像“x374”这样的命名，因为它不能表达任何意义。

　　至于说保密的代码与其他部分代码不一致的问题，这正说明了他们的测试不是很严格。测试对于重构来说，是非常重要的支撑。

　　重构与测试

　　比尔：你在《重构》这本书里写道：“如果你打算重构，那么最基本的前提是有完善的测试。”这是不是说，如果没有测试，就不要重构？

　　马丁：没有测试支撑的重构，就如同不系安全带走钢丝。如果你很擅长走钢丝，而且钢丝又不是悬得很高的话，那不妨试试。但如果你从没走过钢丝，而钢丝又是悬在尼亚加拉瀑布上空，那你最好还是有个保靠的安全带。

　　比尔：如果你目前没有任何测试，那么还有必要追加测试么？

　　马丁：还是那句话，代码的一致性可能会因为某人的修改而被破坏，你绝对不希望会有这样的“惊喜”。而类似 JUnit 的测试的最大好处就是让你能通过运行它们看看是否有什么东西被破坏了。如果你不打算碰你的代码，那当然平安无事；但只要你加新的功能或是修补漏洞，那么你 就有可能破坏某些东西。你的测试越完善，你对能做的改动就越有信心。最终，你能实现比较高的可靠度。

　　以测试为基础的可靠性是极限编程中不大被人们注意的要点之一。人们在谈论极限编程的时候，谈得最多的是它的快速反应力以及轻量化的开发过 程，但往往不提可靠性。而我听到越来越多的故事，都表明极限编程有非常高的可靠性。两周前，我跟以前在 C3 项目的老同事里奇（Rich Garzaniti）聊了聊。克莱斯勒的 C3 项目通常被认为是极限编程的摇篮。在那里，肯特第一次把各种实践有机地结合在一起。里奇谈到了他借助极限编程以及测试和重构所开发的项目。整个系统彻底贯 彻了极限编程的精要。今年到目前为止，他只发现了一处漏洞。

　　测试与效率

　　比尔：在《重构》这本书中，你写道：“作为一个程序员，我写测试是为了提高了自己的工作效率。”那么，测试是否能提高鲁棒性、质量和可靠性呢？

　　马丁：会的，这些都是测试带来的好处。我认为，程序中的缺陷影响了我们的效率，因为我们不得不花时间去修正它们。如果我能 减少一个缺陷，我的效率就得到了提高。至于说我得到了更鲁棒、更可靠的软件，这都是很有价值的副产品。最基本的一点，还是在于我能节省下跟踪和修补漏洞的 时间，从而编写出更多的功能。