舊文重發：談企業軟體架構設計

這篇專訪是ZDNET的李寧編輯在2007.03月期間做的。

[編者語]
最近在網上讀到了“殺不死的人狼——我讀《人月神話》”系列文章。是周愛民關於《人月神化》的讀書心得。《人月神化》在軟體工程裡一本很有分量的書，講述了Brooks博士在IBM公司 System/360家族和OS/360中的專案管理經驗。周愛民在他的這一系列文章中用自己架構師經曆為基礎，從他的視角重新品讀了這本書。而這也使我有了採訪下他的想法，從中我們也許可以瞭解到中國企業內軟體架構設計這個環節的現狀。目前周愛民是盛大網路架構師。想與ZDNet技術專家一起分享你的智慧嗎？請聯絡我leesbfpsj#hotmail.com.

在此特別感謝周愛民在百忙中抽出時間回複了這次訪談。

1， 您好，請先向我們的網友簡單做一下自我介紹好嗎？
================

我94年開始學習電腦，基本上從一開始就學編程。從96年開始涉及商業軟體開發，到現在約十一年了。其間我在鄭州的一家軟體公司呆了7年，曆經了一家軟體公司的中興到消亡，因而也意識到工程、管理在軟體企業——當然也包括其它類型的企業——中的價值。後來，從03年開始的一年多時間，我在鄭州的另一家公司任軟體部經理，也開始實踐自己的工程和管理思想。很好，到現在我離開這家公司一年多了，公司狀況依然很不錯。我認為，團隊或公司並沒有因為你的缺席而變得糟糕，那便已經是良性管理的表現了。關於“Borland Delphi產品專家”，其實更多的是一個圈子的認可，而非行業的認可。我在“大富翁論壇（delphibbs.com）”活動了很長的時間，得到了一些朋友們的認可，後來Borland要評選這個專家的時候，大家推舉了我，於是就得了這個稱號。其實在我看來，優秀的人才、專家很多，我大約是人緣好點，運氣好點罷。

我05年9月開始到盛大網路，任架構師一職。當時Borland China也有offer，但在顧問、軟體工程師與架構師之間，我選擇了架構師這個職務，因為我對這個角色更加感興趣。我目前的工作，主要是盛大的軟體平台方面的架構、設計和一些實施方面的事務。雖然很多人認為盛大是做遊戲的公司，但我基本不涉及遊戲產品的開發。

在開發技術方面，我03年出版過一本《Delphi原始碼分析》。在工程方面，《大道至簡——軟體工程實踐者的思想》一書在下月初就應出版了，它的第一版是以電子版的形式發布的。我在寫的第三本書則是講電腦語言的，題材是“動態函數式語言”。

 2，您做為盛大網路的架構師，請介紹一下在軟體項目中平台架構師是一份怎樣的角色？主要處理哪些工作？
================

架構師有很多種。很多人把體系架構師與架構師等同，其實不對。各類架構師基本素質要求大抵一致，例如分析能力、設計的技術方法，以及對設計目標的前瞻性。但是他們的專業素質會有一些差別。舉個執行個體來說，如果讓我設計遊戲引擎的架構，我就會做不好。但是，如果這個遊戲引擎要設計成一個獨立的平台層次，具有語言無關性、平台整合能力，或是對不同類型遊戲的統一支撐，那麼就是平台架構師的職責了。

具體來說，平台架構師會決策某個部分與其它部分的相互關係、介面的規約和檢測評估它們的方法。如果一個遊戲引擎只為某個遊戲而設計，那麼是用不到平台架構師的。但如果Ａ遊戲中的引擎要移植到Ｂ遊戲，或者更多的遊戲，甚至只是抽離它的部分，以作為某種體系中的一個資料互動層，那麼就需要平台架構師來考量技術上的可行性、穩定性以及它對於更大範圍內的平台建設的價值——當然，如果沒有價值，架構師也會否定它。

平台是長期建設的。平台架構師的重要職責之一，就是長期的規劃和持續的推進。所以平台架構師的工作總是伴隨客戶的戰略決策的。如果一個設計只是解決短期的技術問題，那麼也並不需要平台架構師，但如果是幾年或十幾年要在上面持續經營的一個整體方向，那麼平台架構師就需要圍繞戰略來設計架構的藍圖，並決定規劃的實施步驟。在這些方面，他可能需要協調很多團隊一起來工作。不過，這可不是跟專案經理搶飯碗。因為專案經理重在實施，而架構師重在規劃。

當然，事實上我也做一些其它類型的架構設計工作。例如設計一個小的模組，或者一個業務工件。好的架構師不會拒絕這些工作，而是從更多的、細節的工作中發現整體與局部的關係。也只有觸及到具體工作的細節，架構師才可能更早地發覺設計上的隱患或者與目標的偏差。

 3，《人月神話》這本書30多年來一直被認為是專案管理者的必讀書，最近也看到您的blog裡寫了一系列相關的書評。您是怎麼看到書中“項目實施法則“和實際項目工作之間的關係。
================

這幾個問題我基本上都在《殺不死的人狼》一文中講過了。概括來說，我認為有以下三點：

一、討論“有或沒有”銀彈這樣的話題沒有意義，因為《人月神話》所述的人狼根本殺不死，而且Brooks所設想的銀彈也過於學術。
二、《人月神話》從廣義工程的角度設定了這個命題，這個命題的根本目標與次要目標正好與具體工程（狹義工程）相反。
三、我承認《人月神話》神話所述的答案以及建議在如今的軟體工程中得到了體現。但我們應該更清醒地辨析出現象、答案與本質，並分析哪些是本質的自然延伸，而哪些只是《人月神話》所帶來的影響——Brooks預言了未來，也就改變了未來，即使未來未必應該如此。

與大多數人不一樣的是，我更多的是從與Brooks的預言不一致的那些現象是去發現一些東西。我所看到的是，正是在改變了Brooks的命題，或者認識到他所述的“本質”未必正確的時候，我們才找到了一些“不一樣的成功”。我提醒大家關注這些案例，以及它們與傳統工程、廣義工程的本質差異。

我並不反對《人月神話》中的大多數工程觀點，以及我們現在的軟體業中的工程實踐經驗。但是狹義工程沒有必要去追尋銀彈或那些看起來像是銀彈的東西，我們應該更加靈活。

4企業在進行項目的軟體架構設計時，需要考慮哪些關鍵的問題？
================

企業實施過程中的架構問題，可以分成兩個部分來考慮。一個是軟體企業自身，一個是工程的勘探（有些時候它與前者一則）。基本上來說，架構設計首先是面向客戶的，甚至在整個工程的絕大多數時候都面向客戶。因為理解決定設計，所以讓架構師儘可能早地、深入地瞭解工程目標、應用環境、戰略決策和發展方向，是至關重要的。否則，架構師是不可能做出有效設計來的。

架構設計關注於三個方面：穩定、持續和代價。

穩定性由架構師的設計能力決定。架構的好壞是很難評判的，但基本的法則是“適用”。如果一個架構不適用，那麼再小或者再大都不可能穩定。所因此進一步推論是“架構必須以工程的主體目標為設計象”。看起來這是個簡單的事，但事實上很多架構設計中只是在做邊角功夫，例如為一兩處所謂的“精彩的局部”而叫好，全然不顧架構是否為相應的目標而做。

持久性由架構師的地位決定。如果不能認識“設計的一致性”，以及架構師對這種一致性的權威，那麼再好的架構也會面臨解體，再長遠的架構也會在短期內被廢棄。架構的實施是要以犧牲自由性為代價的，架構師沒有足夠的地位（或權威），則不可能對抗實施者對自由的渴望。通常的失敗，並在於架構的好或壞，而是架構被架空，形同虛設。

代價的問題上面有過一點討論，但方向不同。這裡說明的是，如果架構師沒有充分的經驗，不能準確評估所設計的架構的資源消耗，那麼可能在項目初起便存在設計失誤；也可能在項目中困於枝節，或疏離關鍵，從而徒耗了資源。這些都是架構師應該預見、預估的。

對於企業設計來說，上面三個方面沒有得到關注的結果就是：遲遲無法上線的工程、半拉子工程和不停追加投資的工程項目。我不否認專案經理對這些問題的影響，但事實上可能從設計就開始出了問題，而專案經理只是回天乏術罷了。

最後說明一下，我認為目前大多數的企業專案都缺乏架構上的考量。大多數軟體公司只是出於自身的需要（例如組件化和規模開發）而進行架構設計。這樣的設計不是面向客戶的，事實上這增加了客戶投資，而未能給客戶項目產生價值。這也是我強調架構面向客戶的原因之一。

 5  目前，你的團隊在使用什麼樣的產品或者方法來進行軟體架構設計？
================

架構設計的主要輸出是文檔，因而並沒有什麼特別的工具來協助你做架構設計。很多工具是輔助分析的，例如MindMananger；另外一些則可能輔助你表述，例如Together和Rose。

大多數技術出身的架構師會僅把“軟體編寫的東西”才稱為工具。其實不然，會議室裡的那面白板也是我的工具之一。放開思路，市場規劃圖、技術架構路標圖、特性／收益規劃圖等等這些圖表也是我們的工具。除開這些之外，模式語言和建模語言也是主要的、形式化的工具。

我經常按RUP的規範寫文檔，也偶爾放棄其中的某些具體格式。這些既有的文件範本也是工具。當然，毋庸置疑的是這樣的工具也包括WORD和PowerPoint——很多人並不知道，我有1/4的設計是先用PowerPoint/Visio來完成的。

具體到方法，則非常多了，但應用哪一種則與情境有關。不過最先做的則是分層，這與自頂向下的結構分析很象——事實上在分析和設計的最初階段，這種方法幾乎是必須的。 

6，您覺得國內外軟體架構設計這個環節的主要不同在哪裡？
================

正如你這個問題所表現出來的一樣：我們太注重於工程環節的某個局部。

國外軟體行業在工程實踐經驗上已豐富得多，因此大多數程式員、專案經理或測試人員等等對工程的理解也深刻得多。他們並不自恃於當前的環節，也不否認其它環節。這意味著在整體實施中大家更容易達成一致。然而國內的軟體工程則很少強調這種合作，專案經理強調管理，程式員強調技術，架構師強調一致性和持久性，測試人員則很開心的看到每一個錯誤並以其數量作為評核依據。

顯然這裡出了問題：我們的合作環節在各自為戰。大家都在強調自己的重要性，於是工程就沒法做了。解決的法子，還是讓大家都意識到對方工作的目標與職責，而不僅僅是瞭解自己的那個小圈子。 

7，可以介紹一下你目前的Qomo項目嗎？我們的網友該如何參與？
================
Qomo（Qomolangma OpenProject）是一個JavaScript上的開源項目。目前Qomo 1.0正式版已經發布了。Qomo V1以語言補實為基本思想，在JavaScript上擴充了AOP、OOP、IOP和GP等編程方法，基於它自身的完備的實現，Qomo也提供了Builder和Profiler工具和相關的庫。

Qomo V1隻是整個Qomolangma OpenProject構想中的一很小一部分——儘管它重要。Qomo項目提出的整體目標是：
　－Qomo核心是足夠強大的能應用在不同的JavaScript宿主環境下的通用擴充。
　－Qomo有能力提供膠合不同的應用環境下功能需求的中間代碼。
　－Qomo可以作為定製的宿主應用的程式碼封裝的一個部分以提升應用的體驗或局部效能。

所以Qomo V1並不完備。即便是我們正在展開的Qomo V2，也並不完備。V2計劃提供組件庫、資料庫存取層和圖形表現層。此外，Qomo V2也打算啟用數個實踐項目，一方面作為Qomo的範例，另一方面也驗證Qomo的設計。

Qomo已經在sourceforge上註冊過，但在那裡表現並不活躍。你可以總是從我的blog上得到Qomo的最新訊息，包括Qomo的計劃與每個版本發布。至於參與這個項目，請發mail給我。

我的連絡方式（mail/msn/gtalk）: aiming@gmail.com

 

與本訪談相關的資訊：

“新手的開源之路”
http://blog.csdn.net/aimingoo/archive/2006/01/27/589274.aspx

Qomolangma.V1.0的發布說明
http://blog.csdn.net/aimingoo/archive/2007/02/06/1503015.aspx

殺不死的人狼——我讀《人月神話》
http://blog.csdn.net/aimingoo/archive/2007/03/12/1526396.aspx