我是一個幸運的家伙
——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： 對全世界的程序員我都是那么幾條建議。第一，每年學習并熟悉一個新的編程語言。堅持幾年，你對于程序設計會有非常深刻的見解。第二，學習測試驅動開發，這 種新的方法會改變你對于軟件開發的看法。第三，勞逸結合，不要總是繃得緊緊的，爬爬山，跳跳舞，經常放松神經，你會發現你更有活力和創造力。我的一些最好 的想法就是在山頂上萌發的。