[專家書評] 軟體設計貴在務實——評《軟體架構設計》

架構設計貴在務實

我最早聽說“軟體架構”這個概念以及UML的名字，是在1999年的水木清華BBS上。當時有一篇文章介紹了軟體架構作為一個相對獨立的領域的發展情況，順便提到在此前一年被接納為OMG標準的UML。該文作者斷言，UML的出現將能“徹底”改變軟體開發的工作方式，甚至“若干年之後，不通UML者無法染指軟體開發”。三年之後，《程式員》雜誌專訪Ivar Jacobson時，UML已經是盡人皆知。記得Jacobson在那次採訪中勸告中國的開發人員，趕快去學習RUP。從那時候起，越來越多的人頂上了“軟體架構師”的頭銜，張口模式閉口架構，一時間好不風光。然而最初的熱乎勁過去之後，人們發現，“不通UML者無法染指軟體開發”的預言似乎落了空，而一些軟體架構師們似乎也並不那麼神乎其技，很多時候反而不如那些實實在在寫代碼的人管用。他們所宣傳的那些疊床架屋的抽象層，那些複雜精緻的模式設計，看上去精美無比，柔性十足，然而實踐當中一個出乎意料的小變更，便常常能把這一切打得粉碎。他們樂談的松耦合，小介面，往往只是說起來好聽，實際很難落實，或者代價過高，有的時候，反而是反其道而行之，才更“管用”。

為什麼會出現這種情況？我想這裡有客觀和主觀的原因。就客觀原因來說，軟體開發畢竟還是年輕的行業，各方面還在劇烈發展和變化中。如果把軟體技術做一個層次劃分的話，軟體架構及設計屬於上層建築，而像程式設計語言、技術平台、資料管理技術、網路體繫結構等，均在其之下，屬於基礎。這幾年隨著互連網的飛速發展，基礎尚且在劇烈變化當中，上層建築自然會搖搖晃晃，甚至趕不上趟。具體來說，當今的軟體體繫結構設計總體上是基於物件導向思想，而且是強型別語言時代的物件導向思想，而動態語言的出現和流行，實際上很大程度顛覆了傳統物件導向思想的一些原則。例如，人們曾經認為封裝非常重要，對象成員能夠隱藏便應當盡量隱藏，但是Python和Ruby中public是常態，private反而是變態，實踐當中也工作得很好，甚至更好。再例如，幾年來人們津津樂道的設計模式，其中有很多在動態語言裡毫無必要。而很多在關聯式資料庫時代被視為瑰寶的資料存放區與訪問模式，放到後關係型資料庫裡就全無意義了。再諸如應用的Web化、RIA、SOA等基本思想的變遷，都是能引起整個軟體技術格局強烈震蕩的大事件，所有這些進行中的劇烈變化，不可能不對軟體架構的設計產生影響，從而使得很多關於架構設計的思想迅速過時或者必須調整。如果架構師們不能夠充分重視實踐，與時俱進，那麼就很有可能做出不合時宜的設計。

就主觀原因來說，很多軟體架構師走入了一個誤區，即一旦升級為架構師，就可以脫離具體的代碼實踐，可以陽春白雪了。事實上，由於下層技術的變化迅速，架構師一旦脫離代碼實踐，脫離現實應用，很快就會與實實在在的軟體開發工作產生距離感，忘卻一線開發人員需要面對的現實問題，做出一些不切實際的設計決策。這樣的設計，或者執行不下去，或者執行下去也代價巨大，該解決的問題沒解決，卻在無關緊要的問題上大做文章。毫無疑問，這樣的設計得不到一線開發人員的衷心支援，得不到好的結果。然而，一部分架構師不去檢討自己脫離實踐的設計，卻搞起本本主義，硬拿書本教條死扣實際。相應地，相當多的開發人員也不願意提高對於軟體架構設計的認識和理解。於是兩個必要的角色之間產生矛盾。開發人員抱怨架構設計華而不實，架構師抱怨開發人員不嚴格按設計行事，進而相互質疑對方角色的必要性。開發人員認為架構師沒有存在的必要，而架構師則幻想有朝一日自動代碼產生器能把這幫不聽話的開發人員趕出山門。

事實上，開發人員和架構師都是軟體開發中必不可少的角色，即使在單人開發的項目裡，開發人員本人也需要經常在這兩個角色之間切換。兩個角色的相互理解，和諧協作，才能夠共同克服現實困難，開發成功的軟體。在促進這種和諧的過程中，開發人員應當積極學習架構設計的理論並充分實踐，而架構師則需要本著務實的態度貼近一線。

因為從事技術媒體工作，我也確實結識了幾個優秀的架構設計師，他們身上的共同特點就是務實。這些架構師都具有多年的軟體開發經驗，對軟體本質的理解相當深入，本身就是開發高手。與一般開發高手不同的是，他們充分實踐，但不宥於實踐，而是積極地學習軟體架構的理論，嘗試用理論來指導實踐。而與整天高談闊論的理論架構師不同的是，他們掌握了理論之後，一定要親自落實，用實踐來檢驗。當理論與實踐產生矛盾的時候，他們既不會輕易否定理論，更不會教條主義般地削足適履，而是認真分析矛盾產生的原因，研究可能的對策。在反覆思考和實踐之下，他們敢於做出“離經叛道”的結論，敢於質疑大師偶像的論斷，更能夠在錯綜複雜的實際中做出簡單、可靠、靈活而便於實現的設計，並且向開發人員傳達意圖，答疑解惑，實現整個團隊的思想一致。他們做出的設計，開發人員看得懂，做得出，自然會得到衷心的擁護。

溫昱是《程式員》雜誌的老作者，他本人有豐富的開發經驗，為雜誌撰寫軟體架構設計方面的文章也已經有三四年的時間。因為他在上海工作，我與他只見過寥寥幾面。然而從與他的交流，以及他的文章來看，溫昱也是一位出色的架構設計師。拿到他寫的這本書稿之後，我有粗有細地閱讀了一遍，感到作者不但理論知識豐富，閱讀廣泛深入，設計工具運用自如，而且具有務實精神。書中舉了大量來自開發一線的實際案例，用這些實際案例當中的設計決策來印證和講述理論。當實踐與理論發生矛盾的時候，他也是從實踐出發，認真地分析原因，找出解決之道。通常我並不喜歡滿是UML圖例的圖書，然而溫昱這本書讀起來卻津津有味，不但能夠澄清很多觀念，學到不少知識，而且閱讀過程中有時能進入一種狀態，似乎跟著作者一起思考，甚至跟他發生爭論。我想這正是因為作者的務實精神。讀過此書，再看那些大部頭的架構設計經典，理解起來就更容易，而且，也許是更重要的，也就具備了一種批判而不是盲從的能力。為此，我樂於向希望學習軟體架構設計的開發人員和架構師們推薦這本務實之作。

 

 

孟岩

2007.3.20

於北京