第10章 軟件架構師應該是建造大師

把建筑的隱喻應用到軟件不見得合適，盡管在中世紀，設計建筑的人只是極少數，卻組成了建造大師的高端社團。之所以做這樣的隱喻，是因為建造大師名副其實是他們這門學問的大師，一旦達到了這種高度，建造大師是繼續建造還是讓其他名氣不大的人來做？幾百年后，我們似乎又在對軟件行業問同樣的問題。

聯盟的狀態

在過去的十年間，由于“大型預先設計”和“分析麻痹”等問題，軟件架構已經失寵。這多半源于為了更有效地交付軟件系統，敏捷方法作為主要的催化劑，減少了很多團隊都要做的預先思考的工作量，結果現在“架構師”在軟件團隊里往往被看作是多余的。很多團隊都向著扁平化和自組織努力，從表面上看這不需要再專設技術領導。

另一個因素是，許多人認為架構師都在做高層次的抽象思維。我相信你已經見過“象牙塔架構師”或“PPT架構師”等說法，用來指代那些設計解決方案時從不考慮細節的人。如果我們回顧一下過去，這可不是架構師的角色。

回顧過去

如果你追溯“架構師”（architect）一詞在拉丁語（architectus）和希臘語（arkhitekton）的源頭，直譯就是“首席建筑師”，從字面上看，這些人是他們這行中的佼佼者。在中世紀，“建筑師”一詞指“石匠大師”，因為石頭是當時的主要建筑材料。下面這句話對這個角色做了很好的總結：

石匠大師，就是石頭的操作者、藝術家和設計師。

這句話同樣適用于我們軟件開發者。

建造大師真的會建造嗎

關鍵問題是，建造大師是否真的建造了什么？如果你研究一下人們如何實現“石匠大師”的角色，就會發現一些類似的東西：

盡管石匠大師受人尊敬、通常也很富有，然而在達到行業頂峰之前，他必須經歷石匠、監督的歷練來證明自己的價值。

架構師的維基百科頁面說了相同的話：

在古代和中世紀的歷史中，大多數建筑設計和建設都是工匠完成的：下至石匠和木匠，上至建造大師。

有趣的是，對于這些石匠大師參與過多少建筑，并沒有一個統一觀點。比如：

他實際上做了多少，其實是有爭議的。這個術語可能會有所不同，但是，以我的理解，中世紀石匠大師基本的組織和角色跟今天的首席建筑師是類似的：這也許反映了建筑建造不變的基本。

真正有意義的是看看這個角色承擔了什么。引用另一段話：

頂尖的石匠就是一個石匠大師。然而，建筑大師這個頭銜，指的是全面負責建筑工地、讓石匠大師們為他工作的那個人。建筑大師也負責木匠、玻璃工匠等。實際上，每個建筑工地上的人都在建筑大師的監督下工作。

再加一些額外的細節：

然后，石匠大師為將要建造的東西設計結構、美學和象征等方面的特性，組織后勤，還要評定工作的優先級并決定它們的順序。

象牙塔

如果這聽起來很熟悉，等一等，看看團隊過去是如何工作的：

每一個小石匠都遵循大師設定的方向和對主要結構或美學的所有決定，解決那些問題都是大師的工作。

顯然，容易看出很多軟件團隊的傳統運作方式與此相似，敏捷軟件開發團隊希望采用一種不同的方法也就不奇怪了。很多現代的軟件開發團隊試圖讓一群人分擔技術領導者的角色，而不是安排一個遠離細節的專門角色。當然，很多架構師遠離細節的主要原因之一是他們沒有時間。這通常導致架構師在現實的團隊日常工作中被移除，慢慢變得脫離實際。過去的石匠大師也被這個問題困擾：

看起來同時進行多個任務是很平常的事情，石匠大師很少參與體力工作（即使身體條件允許）也就不足為奇。1261年，尼古拉斯·德·比亞德（Nicholas de Biard）在布道中斥責“只靠言語就做判斷”的石匠大師的明顯懶惰，給出了這一假設的證詞。

下面這段話來自瑞秋·戴維斯和麗茲·賽德利所著的《敏捷教練：如何打造優秀的敏捷團隊》，突出了這種現象在軟件行業中造成的一個常見后果：

如果你了解如何編程，往往會忍不住對開發者該如何編寫代碼提出建議。小心，因為你可能在浪費時間：如果你沒有參與項目的編程，開發者多半會無視你的編碼經驗。他們還會認為你越權，影響了他們的工作，所以盡量別在這方面指指點點。

為了掩蓋這種局面，很多人會把軟件架構的角色看作其組織內的一個高級職位或級別，從而加劇了開發者和架構師之間的脫節。看來，石匠大師也有相同的境遇：

為了避免這種爭斗，文藝復興后期的藝術家們不再被視為只是普通的工匠，而石匠大師似乎被神話（在我看來）為貴族后裔。此外，由于對所掌握知識秘而不宣，他們制造了一種神秘感，讓自己有別于其他不那么“神秘”或“高尚”的職業。

建造大師角色的差異

多數看法都一樣：建造大師并沒有太多時間去建造，盡管他們具備這樣的技能。回到軟件行業，軟件架構師應該寫代碼嗎？我直截了當地回答：“理論上，是的。”更完整的答案可以在這本書里面找到。為什么？因為技術不是一個實現細節，你需要理解為自己的決定所做的取舍。

那么現代建筑師為什么不為實際的建造過程出力呢？為了回答這個問題，我們要看看這個角色這些年是如何演化的：

在古代和中世紀的歷史中，大多數建筑設計和建設都是工匠完成的：下至石匠和木匠，上至建造大師。直到現代，建筑師和工程師之間也沒有明顯的區別。在歐洲，建筑師和工程師的頭銜主要因地域不同而經常交替使用，但指的都是同一個人。

結構工程的維基百科頁面提供了更多信息：

自從人類開始修筑屬于自己的結構，結構工程就出現了。在19世紀末的工業革命期間，建筑專業體現出了與工程專業的不同，成為一個更正式的專業。直到那時，建筑師和結構工程師通常還是同一個人：建造大師。19世紀和20世紀初，隨著結構理論專業知識的發展，專門的結構工程師才開始出現。

本質上，傳統建筑師的角色已經分化為兩種。一種是結構工程師，確保建筑物不倒塌；另一種是建筑師，負責與客戶交流，收集他們的需求，從美學的視角進行建筑設計。馬丁·福勒（Martin Fowler）的bliki有一個頁面談到了兩種角色差異的意義：

軟件架構師被看作是首席設計師，是把項目的每件事凝聚在一起的人。但建筑師可不會干這些。建筑師關注的是與想要建筑的客戶交流。他的精力集中在客戶覺得重要的事情上，比如建筑的布局和外觀。但建筑也不僅限于此。

因其背后蘊含的包括物理定律在內的豐富知識，建筑現在被看作是一門工程學科，這些知識能夠建模和預測建材的行為。相比之下，軟件開發行業還比較年輕，正以驚人的速度發展。今天的建筑大多還是使用和幾百年前相同的材料，但似乎我們每20分鐘就會發明一種新技術。我們生活在“互聯網時代”。除非我們這個行業發展到軟件的構建方式和預測工程項目相同，否則團隊中有人一直跟隨技術的發展，有能力做出如何設計軟件的正確決策，還是很重要的。換句話說，軟件架構師還需要扮演結構工程師和建筑師的角色。

實現角色

最后，簡要地說一下，人們如何實現石匠大師的角色。下面這段話來自維基百科的“石匠工藝”頁面：

中世紀對石匠技能的需求很大，行業協會的成員按水平被劃分為三個等級：學徒、幫工和石匠大師。學徒要和師傅簽訂契約，以此換取師傅的培訓；幫工的技能要高一些，可以到外面去協助別的師傅；石匠大師被看作自由人，可以按自己的意愿選擇主顧的項目。

這反映了我自己擔任軟件架構角色的經驗。它是一個漸進的過程。像很多人一樣，我的職業生涯始于在別人的監督下寫代碼，漸漸地，當我獲得更多的經驗，就開始承擔更大的設計任務。不同于中世紀的建筑行業，對于如何從初級開發者到軟件架構師，軟件開發行業缺乏明確的路線。我們沒有普遍的學徒模式。

架構師要和團隊一起工作

對很多組織來說，這里有個大問題：找不到足夠的架構師。雖然石匠大師可能沒有太多時間自己去跟石頭打交道，但還是和團隊一起工作。我常常遇到一些架構師，他們要協助多個不同團隊。很明顯，如果和多個不同團隊一起工作，要向軟件交付的實踐部分做出貢獻是不現實的，你沒有時間寫任何代碼。

在多個團隊中扮演軟件架構角色，并不是一個有效的工作方式。通常這種情況發生時，都有一個由被視為共享資源的架構師組成的中心組（比如“企業架構組”）。根據我所讀到的，石匠大師任何時候都會只關注一個建筑工地，這也正是我們的軟件開發團隊應該采用的方法。如果你認為這不可能，就看看中世紀建筑行業是怎么解決這個問題的：

每個石匠都會帶一個為他工作的學徒。當石匠接下一份新工作，學徒也會跟著他。如果石匠覺得自己的學徒已經對行當足夠了解，就會讓他在石匠行會接受考驗。

再次回到了典型的學徒模式，這也是為什么指導和輔導應該是現代軟件架構角色的一部分。我們需要培養未來的軟件架構師，每個軟件開發團隊都需要他們自己的建造大師。