我是一個幸運的家伙
——Martin Fowler北京訪談
孟巖 / 記者
2005 年6月初，ThoughtWorks首席科學家、技術(shù)思想大師Martin Fowler來到北京。盡管這次訪問行程繁忙，他還是在離開北京的前一天晚上 抽時間接受了我們《程序員》雜志的采訪。很明顯，連日來馬不停蹄的奔波演講使他相當疲勞，但是正如他自己所說，他用說話的方式寫作，用寫作的方式說話，即 使是在我們不長的交談中，他仍然給我們帶來了很多深刻的啟發(fā)。
記者：您現(xiàn)在是一位對軟件開發(fā)社群有著重大影響力的人，對您來說，您認為取得成功最重要的三個因素是什么？
MF：我認為，排在前三位的是運氣、運氣和運氣。
記者：這太讓我們驚訝了，難道您把您的成功歸結(jié)為運氣嗎？
MF： 我說我有好的運氣是因為恰好在合適的時間做了合適的事情，比如：在面向?qū)ο笈d起的時候，我恰好加入了一個使用面向?qū)ο蟮南蠕h團隊；隨后我又恰好接觸了剛剛 興起的建模技術(shù)；1997年我撰寫了《UML Distilled》，恰好趕上了UMFL的大流行；之后我恰好加入了C3項目，從而見證并且參與了敏捷方 法的誕生；這樣“恰好”了很多次，所以我說我真的太幸運了。
記者：我想這么多連串的幸運應該也是您付出努力才得到的。
MF： 我不知道，但是我卻是在做每件事情都非常投入，可以說是兢兢業(yè)業(yè)，一絲不茍。你知道，我不是一個喜歡預測未來的人，所以從不把時間花在無休止的煩躁和爭論 上，而是盡可能投入眼前的工作。當然像我這樣的人也很多，所以我說，能夠站在現(xiàn)在的位置上，真的完全是靠運氣。當然，提到寫作，我認為我還算是個不錯的作 者，似乎有天賦的表達能力。
記者：是的，我前不久讀了您的《企業(yè)應用架構(gòu)模式》一書，您的表達能力點給我們留下很深的印象。說到所謂的“企業(yè)開發(fā)”，究竟什么叫“企業(yè)開發(fā)”，它究竟有什么特點？
MF： 企業(yè)開發(fā)”是一個很含糊的詞，我一般用它來指代所謂業(yè)務軟件開發(fā)，以區(qū)別于傳統(tǒng)的軟件產(chǎn)品開發(fā)。企業(yè)開發(fā)通常要和數(shù)據(jù)打很多交道，而且時間和資金的壓力很 大，客戶的需求多變，而且需要多次迭代和大量集成性工作。企業(yè)開發(fā)是要遵守一系列業(yè)務邏輯的，而正如我在《企業(yè)應用架構(gòu)模式》一書中所說的，這些業(yè)務邏輯 最大的特點就是沒有邏輯。
記者：那么您認為企業(yè)開發(fā)者所面臨的最大挑戰(zhàn)是什么？
MF：如我所說，企業(yè)應用的業(yè)務邏輯經(jīng)常是沒有邏輯性可言的，因此為了了解它，開發(fā)者必須不斷溝通和交流！只有不斷的溝通和交流才能開發(fā)出用戶真正需要的軟件。
記者：您覺得企業(yè)開發(fā)當前最重要的趨勢是什么？
MF： 我覺得眼下最有趣的趨勢是人們正在竭盡全力地尋找做一件事情最簡單的辦法，怎樣用最簡單的方法構(gòu)造大型的復雜的應用程序和企業(yè)解決方案。比如說：在 Java開源社群中出現(xiàn)的以Spring為代表的輕量級容器。以及Ruby on Rails，它根據(jù)“習俗”來自動設定很多元素，大大提高了開發(fā)效率， 也簡化了開發(fā)過程。
記者：看來您對于Python和Ruby這樣的動態(tài)語言非常感興趣，是嗎？
MF：坦率地說，至少在目前的情況下，大型的、復雜的、嚴肅的應用程序還是以Java和.NET為主，但是對于一些小的應用來說，Python和Ruby這樣的動態(tài)語言確實展現(xiàn)出一些讓人覺得非常有趣的特性，我本人就是一個Ruby的愛好者。
記者：有的企業(yè)開發(fā)者認為，目前的企業(yè)開發(fā)效率已經(jīng)足夠高了，只要將目前的工具和框架掌握得很好，就可以高效率地開發(fā)出高質(zhì)量的企業(yè)應用。您覺得我們的效率真的足夠高了嗎？
MF：不，我并不是這樣認為。我們的開發(fā)效率還有很大的提高空間，尤其是如何快速、清晰地了解客戶需求，并將其轉(zhuǎn)化為符合要求的應用程序。這個過程對于我們目前的企業(yè)開發(fā)來說還是太慢了。
記者：可是，我們幾乎不需要做任何大的設計工作，體系和架構(gòu)是確定的，還有很多框架在輔助我們，并將所有有趣的設計工作都代替我們做了，在這樣的開發(fā)過程中，趣味何在？
MF： 如何快速而準確的滿足業(yè)務需求，對業(yè)務邏輯進行建模才是有趣的事情。而像O/R Mapping這樣的事情，是非常乏味而枯燥的。對我而言，絕不會認為撰 寫一個O/R Mapping的工具是一件有趣的事情。它與業(yè)務本身無關(guān)，而只是作為基礎設施而存在。有這樣的工具我覺得非常好，但是我認為更重要的，還 是把握客戶對業(yè)務的需求。
記者：好吧，那讓我們來談談面向?qū)ο蟮乃枷耄@可以說是當今企業(yè)開發(fā)的主流思想，我記得您曾經(jīng)在書中說過，面向?qū)ο笫沟脴?gòu)造大型復雜系統(tǒng)成為可能，但是現(xiàn)在SOA正在興起，您覺得這是否意味著面向?qū)ο笠^時了呢？
MF： 當然不，談到服務，其實在服務的背后仍然是面向?qū)ο螅帐潜┞豆δ艿囊环N方式，而在背后提供功能的，仍然是對象。而且開發(fā)這些功能仍然需要大量面向?qū)ο?技術(shù)。總而言之，服務關(guān)注的是如何對外暴露接口，而在這些接口背后的構(gòu)建工作仍然非常復雜，面向?qū)ο鬄檫@些工作提供了一種很好的解決方法。
記者：在中國，由于一般企業(yè)的管理還不成熟，所以客戶的需求變化頻繁而且劇烈，很難保持接口的穩(wěn)定，有人認為面向?qū)ο笤谶@種情況下并不適合使用，因此把希望寄托在SOA上，您對此如何看待？
MF： 我覺得這種觀點是很奇怪的，說到接口的不穩(wěn)定，無論是對對象還是對服務都同樣是存在的。在服務中也需要像契約這樣的手段對外發(fā)布功能，因此同樣存在接口不 穩(wěn)定的情形。所以SOA根本解決不了這個問題。我認為這更多的是一個開發(fā)方法的問題，例如敏捷開發(fā)中，頻繁地改變對象的接口，通過與客戶的密切交流來了解 和滿足業(yè)務需求，同時通過重構(gòu)來調(diào)整應用程序的內(nèi)部結(jié)構(gòu)，這樣至少會使接口盡早穩(wěn)定下來。同時也應該為接口的進化提供一種行之有效的手段。這個問題確實不 好回答，這說的只是一個基本思路。
記者：問您一個具體的技術(shù)問題。在很多企業(yè)應用中，人們都會開發(fā)一個數(shù)據(jù)訪問層，這是為什么呢？為什么不直接在業(yè)務邏輯層中存取數(shù)據(jù)庫？
MF：我本人喜歡在不同的地方作不同的事情。業(yè)務邏輯是一回事，存取數(shù)據(jù)庫是另外一回事，所以它們不應該糾纏在一起。這是主要的理由。還有一個次要的理由，設計一個數(shù)據(jù)訪問層，一旦數(shù)據(jù)庫發(fā)生變化，移植起來會快得多。
記者：但是這樣的設計也有缺點。當我們要改動數(shù)據(jù)表結(jié)構(gòu)時，往往需要相應地在數(shù)據(jù)訪問層做改動，接著在業(yè)務邏輯層作改動，有時甚至要改表現(xiàn)層。這不是很麻煩嗎？
MF：哈，這是人們經(jīng)常抱怨的事情，但是這就是所謂的trade-off。分層在帶來一些好處的同時也帶來了這樣的麻煩。
記者：再說說單元測試。很多人不愿意進行單元測試，是因為時間的壓力太大了。如果項目時間很緊張，難道我要花掉一半的時間來寫單元測試？
MF：當然！因為單元測試能夠使你更快地完成工作。無數(shù)次的實踐已經(jīng)證明這一點。你的時間越是緊張，就越是要寫單元測試，它看上去慢，但實際上能夠幫助你更快、更舒服地達到目標。
記者：道理固然如此，但是實際上很多人沒有心情去寫完備的單元測試...
MF：在這種情況下，你可以只寫那些確保代碼在正常情況下正常工作的單元測試，不必應對各種各樣的錯誤情形。
記者：即使這樣也還是很煩人。我發(fā)現(xiàn)自己經(jīng)常在測試一些顯而易見的事實，比如一加一等于二，還經(jīng)常把精力放在一些不重要的測試上。
MF：什么叫重要？什么叫不重要？這是需要逐漸認知的，不是想當然的。我為絕大多數(shù)的模塊寫單元測試，是有點煩人，但是當你意識到這工作的價值時，你會欣然的。
記者：您能給中國程序員幾個忠告或者建議嗎？
MF： 對全世界的程序員我都是那么幾條建議。第一，每年學習并熟悉一個新的編程語言。堅持幾年，你對于程序設計會有非常深刻的見解。第二，學習測試驅(qū)動開發(fā)，這 種新的方法會改變你對于軟件開發(fā)的看法。第三，勞逸結(jié)合，不要總是繃得緊緊的，爬爬山，跳跳舞，經(jīng)常放松神經(jīng)，你會發(fā)現(xiàn)你更有活力和創(chuàng)造力。我的一些最好 的想法就是在山頂上萌發(fā)的。