我是一个幸运的家伙
                                                                                          ——Martin Fowler北京访谈

                                                                                                               孟岩 / 记者
 
2005 年6月初，ThoughtWorks首席科学家、技术思想大师Martin Fowler来到北京。尽管这次访问行程繁忙，他还是在离开北京的前一天晚上 抽时间接受了我们《程序员》杂志的采访。很明显，连日来马不停蹄的奔波演讲使他相当疲劳，但是正如他自己所说，他用说话的方式写作，用写作的方式说话，即 使是在我们不长的交谈中，他仍然给我们带来了很多深刻的启发。
记者：您现在是一位对软件开发社群有着重大影响力的人，对您来说，您认为取得成功最重要的三个因素是什么？
MF：我认为，排在前三位的是运气、运气和运气。
记者：这太让我们惊讶了，难道您把您的成功归结为运气吗？
MF： 我说我有好的运气是因为恰好在合适的时间做了合适的事情，比如：在面向对象兴起的时候，我恰好加入了一个使用面向对象的先锋团队；随后我又恰好接触了刚刚 兴起的建模技术；1997年我撰写了《UML Distilled》，恰好赶上了UMFL的大流行；之后我恰好加入了C3项目，从而见证并且参与了敏捷方 法的诞生；这样“恰好”了很多次，所以我说我真的太幸运了。
记者：我想这么多连串的幸运应该也是您付出努力才得到的。
MF： 我不知道，但是我却是在做每件事情都非常投入，可以说是兢兢业业，一丝不苟。你知道，我不是一个喜欢预测未来的人，所以从不把时间花在无休止的烦躁和争论 上，而是尽可能投入眼前的工作。当然像我这样的人也很多，所以我说，能够站在现在的位置上，真的完全是靠运气。当然，提到写作，我认为我还算是个不错的作 者，似乎有天赋的表达能力。
记者：是的，我前不久读了您的《企业应用架构模式》一书，您的表达能力点给我们留下很深的印象。说到所谓的“企业开发”，究竟什么叫“企业开发”，它究竟有什么特点？
MF： 企业开发”是一个很含糊的词，我一般用它来指代所谓业务软件开发，以区别于传统的软件产品开发。企业开发通常要和数据打很多交道，而且时间和资金的压力很 大，客户的需求多变，而且需要多次迭代和大量集成性工作。企业开发是要遵守一系列业务逻辑的，而正如我在《企业应用架构模式》一书中所说的，这些业务逻辑 最大的特点就是没有逻辑。
记者：那么您认为企业开发者所面临的最大挑战是什么？
MF：如我所说，企业应用的业务逻辑经常是没有逻辑性可言的，因此为了了解它，开发者必须不断沟通和交流！只有不断的沟通和交流才能开发出用户真正需要的软件。
记者：您觉得企业开发当前最重要的趋势是什么？
MF： 我觉得眼下最有趣的趋势是人们正在竭尽全力地寻找做一件事情最简单的办法，怎样用最简单的方法构造大型的复杂的应用程序和企业解决方案。比如说：在 Java开源社群中出现的以Spring为代表的轻量级容器。以及Ruby on Rails，它根据“习俗”来自动设定很多元素，大大提高了开发效率， 也简化了开发过程。
记者：看来您对于Python和Ruby这样的动态语言非常感兴趣，是吗？
MF：坦率地说，至少在目前的情况下，大型的、复杂的、严肃的应用程序还是以Java和.NET为主，但是对于一些小的应用来说，Python和Ruby这样的动态语言确实展现出一些让人觉得非常有趣的特性，我本人就是一个Ruby的爱好者。
记者：有的企业开发者认为，目前的企业开发效率已经足够高了，只要将目前的工具和框架掌握得很好，就可以高效率地开发出高质量的企业应用。您觉得我们的效率真的足够高了吗？
MF：不，我并不是这样认为。我们的开发效率还有很大的提高空间，尤其是如何快速、清晰地了解客户需求，并将其转化为符合要求的应用程序。这个过程对于我们目前的企业开发来说还是太慢了。
记者：可是，我们几乎不需要做任何大的设计工作，体系和架构是确定的，还有很多框架在辅助我们，并将所有有趣的设计工作都代替我们做了，在这样的开发过程中，趣味何在？
MF： 如何快速而准确的满足业务需求，对业务逻辑进行建模才是有趣的事情。而像O/R Mapping这样的事情，是非常乏味而枯燥的。对我而言，绝不会认为撰 写一个O/R Mapping的工具是一件有趣的事情。它与业务本身无关，而只是作为基础设施而存在。有这样的工具我觉得非常好，但是我认为更重要的，还 是把握客户对业务的需求。
记者：好吧，那让我们来谈谈面向对象的思想，这可以说是当今企业开发的主流思想，我记得您曾经在书中说过，面向对象使得构造大型复杂系统成为可能，但是现在SOA正在兴起，您觉得这是否意味着面向对象要过时了呢？
MF： 当然不，谈到服务，其实在服务的背后仍然是面向对象，服务是暴露功能的一种方式，而在背后提供功能的，仍然是对象。而且开发这些功能仍然需要大量面向对象 技术。总而言之，服务关注的是如何对外暴露接口，而在这些接口背后的构建工作仍然非常复杂，面向对象为这些工作提供了一种很好的解决方法。
记者：在中国，由于一般企业的管理还不成熟，所以客户的需求变化频繁而且剧烈，很难保持接口的稳定，有人认为面向对象在这种情况下并不适合使用，因此把希望寄托在SOA上，您对此如何看待？
MF： 我觉得这种观点是很奇怪的，说到接口的不稳定，无论是对对象还是对服务都同样是存在的。在服务中也需要像契约这样的手段对外发布功能，因此同样存在接口不 稳定的情形。所以SOA根本解决不了这个问题。我认为这更多的是一个开发方法的问题，例如敏捷开发中，频繁地改变对象的接口，通过与客户的密切交流来了解 和满足业务需求，同时通过重构来调整应用程序的内部结构，这样至少会使接口尽早稳定下来。同时也应该为接口的进化提供一种行之有效的手段。这个问题确实不 好回答，这说的只是一个基本思路。
记者：问您一个具体的技术问题。在很多企业应用中，人们都会开发一个数据访问层，这是为什么呢？为什么不直接在业务逻辑层中存取数据库？
MF：我本人喜欢在不同的地方作不同的事情。业务逻辑是一回事，存取数据库是另外一回事，所以它们不应该纠缠在一起。这是主要的理由。还有一个次要的理由，设计一个数据访问层，一旦数据库发生变化，移植起来会快得多。
记者：但是这样的设计也有缺点。当我们要改动数据表结构时，往往需要相应地在数据访问层做改动，接着在业务逻辑层作改动，有时甚至要改表现层。这不是很麻烦吗？
MF：哈，这是人们经常抱怨的事情，但是这就是所谓的trade-off。分层在带来一些好处的同时也带来了这样的麻烦。
记者：再说说单元测试。很多人不愿意进行单元测试，是因为时间的压力太大了。如果项目时间很紧张，难道我要花掉一半的时间来写单元测试？
MF：当然！因为单元测试能够使你更快地完成工作。无数次的实践已经证明这一点。你的时间越是紧张，就越是要写单元测试，它看上去慢，但实际上能够帮助你更快、更舒服地达到目标。
记者：道理固然如此，但是实际上很多人没有心情去写完备的单元测试...
MF：在这种情况下，你可以只写那些确保代码在正常情况下正常工作的单元测试，不必应对各种各样的错误情形。
记者：即使这样也还是很烦人。我发现自己经常在测试一些显而易见的事实，比如一加一等于二，还经常把精力放在一些不重要的测试上。
MF：什么叫重要？什么叫不重要？这是需要逐渐认知的，不是想当然的。我为绝大多数的模块写单元测试，是有点烦人，但是当你意识到这工作的价值时，你会欣然的。
记者：您能给中国程序员几个忠告或者建议吗？
MF： 对全世界的程序员我都是那么几条建议。第一，每年学习并熟悉一个新的编程语言。坚持几年，你对于程序设计会有非常深刻的见解。第二，学习测试驱动开发，这 种新的方法会改变你对于软件开发的看法。第三，劳逸结合，不要总是绷得紧紧的，爬爬山，跳跳舞，经常放松神经，你会发现你更有活力和创造力。我的一些最好 的想法就是在山顶上萌发的。