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

為什么會出現這種情況？我想這里有客觀和主觀的原因。

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

就主觀原因來說，很多軟件架構師走入了一個誤區，即一旦升級為架構師，就可以脫離具體的代碼實踐，可以陽春白雪了。事實上，由于下層技術的變化迅速，架構師一旦脫離代碼實踐，脫離現實應用，很快就會與實實在在的軟件開發工作產生距離感，忘卻一線開發者需要面對的現實問題，做出一些不切實際的設計決策。這樣的設計，或者執行不下去，或者執行下去也代價巨大，該解決的問題沒解決，卻在無關緊要的問題上大做文章。毫無疑問，這樣的設計得不到一線開發者的衷心支持，得不到好的結果。架構設計跟開發發生矛盾，誰有問題？多半是架構設計出了問題。因為開發直接面對實踐，直接從事實踐，開發出了問題，那就是實踐在向自以為是的偽真理宣戰了。然而，一部分架構師不去檢討自己脫離實踐的設計，卻搞起本本主義，硬拿書本教條死扣實際。另一方面，如果開發者對于架構設計的原則和嘗試缺乏了解，不愿意提高對于軟件架構設計的認識和理解，不愿意付出對長遠有利的代價，也不理解，不支持，甚至消極抵制架構師的決定，那么同樣會引起架構設計與開發之間的矛盾。結果往往是，兩個必要的角色之間產生矛盾。開發者抱怨架構設計華而不實，架構師抱怨開發者不嚴格按設計行事，進而相互質疑對方角色的必要性。開發者認為架構師就是吃干飯的文人，根本應該人間蒸發，沒有存在的必要，而架構師則覺得開發者是一群無組織無紀律的驕傲的野貓，幻想有朝一日自動代碼生成器能把這幫不聽話的開發者趕出山門。

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

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