Posted on 2005-12-20 23:25
非魚 閱讀(3219)
評論(6) 編輯 收藏 所屬分類:
面向對象設計
軟件架構師不是建筑架構師。他們之間除了名字,沒有任何的共同之處。把軟件架構師和建筑架構師類比,甚至把他們等同起來,是一種錯誤的觀念。
建筑是實體的,軟件是形式的。實體的建筑以結構為其主要內容,輔以少量動態的考慮(給水、排水及其他)。軟件則是靜態的結構和動態的行為的結合體。從這個
角度,建筑師的建模主要是靜態的建模,比一個機械工程師,他多了藍圖的繪制的工作;而一個軟件架構師不僅要對軟件的結構進行建模,還要對軟件的運行時刻的
行為建模。
建筑是一次性的,軟件是演變的。雖然我們也說“舊城改造”,但那是拆了重建,而不是在原基礎上改造。一棟造好的樓房,是不能在上面再增加一層的。軟件則是
在原基礎上修改,以滿足用戶需要。在這個前提下,建筑的架構是不會改變的;而軟件在多次修改的情況下很可能觸及架構上的變動。所以軟件架構師必須在軟件的
整個生命周期中時刻注意架構是否會變化,并且可能會主動調整它。
在建筑設計中,必須滿足結構力學等基本原理,否則生產出來的建筑本身的使用質量沒有保證,這是一個強制的要求,也存在相關標準。而軟件在設計上只有一堆原
則,指導我們設計。即使你沒有遵循這些原則,生產出來的產品一般也是可用的,具有使用質量,但產品改進的質量就難說了。因此軟件的設計也比較難以把握,生
產一堆可用的垃圾的情況比較普遍。
建筑投資商往往給出一些量化的數據,建筑師把這些量化的數據轉變成一個實際的建筑,在這個過程中一般不會有大的偏差。而軟件尤其是應用軟件,強烈依賴于用
戶的需求。我們設計應用軟件,基本上等同于對用戶的行為進行建模,在目前對于人類行為的研究遠遠低于對于基礎數學、物理學研究的情況下,一次成型的軟件是
不可能存在的。應用軟件的開發,基本可以描述為“在變化的基礎上工作”。
在滿足使用質量的前提下,建筑師極力追求建筑的外形。而軟件也有這樣做的(國產的一些網頁,大家是否也覺得惡心呢?)。但一般用戶在滿足其開始的外在表現
的要求之后,慢慢就越來越關注軟件的內容,關注軟件是否真的幫助到了他們的生活,并且開始發起一次次的修改請求。
綜上所述,軟件架構師和建筑師的差別巨大,試圖以建筑師的角度解釋軟件架構師,甚至想找到一個類似的解決之道,是不可行的。而對于初步接觸架構師的人來
說,總是把架構師和建筑師對比也很容易誤導他們。類比固然可以幫助理解,但也可能造成誤解。
從另一個角度考慮,假設軟件架構師和建筑師確實可以互通,那么如果存在一個既是軟件架構師又是建筑師的人,他就可以領導軟件產業一往無前
了。可是這么多年來,為什么沒有這樣一個人呢?
評論
# re: 架構師不是建筑師 回復 更多評論
2005-12-21 08:44 by
不過感覺還是差不多,都是畫圖紙的。而我則是下面和泥砌磚的:)
# re: 架構師不是建筑師 回復 更多評論
2005-12-21 10:16 by
其實我一直有一個想法,將軟件開發和建筑和機械等類比其實是不合適的,其實更應該和寫作或者電影拍攝類比。
因為軟件開發的產品,其實是人的思想的固化物,是對人類社會中的業務、規則、關系的描述、體現和抽象。所以做一個好的軟件,其實就象拍一部好電影一樣難,要有優秀的劇本/編劇(架構師),卓越的導演/制片(PM),最好還要天才的演員(開發人員)。
還沒想好。。。。。。。
# re: 架構師不是建筑師 回復 更多評論
2005-12-21 12:38 by
關于架構師更像導演而不是建筑師的問題
可見《成功的軟件項目管理-銀彈方案》一書
愛爾蘭作者費格斯在其中做了精彩的闡述
# re: 架構師不是建筑師 回復 更多評論
2005-12-22 11:44 by
我個人感覺還是,比較接近的。
之所以現今的軟件架構與建筑架構有較大差異,主要是因為軟件領域和建筑領域的發展階段不同。一個幾十年,一個上千年了。成熟度不一樣。如果類比現今的軟件領域和早期的建筑領域會發現很多共同點的。
# re: 架構師不是建筑師 回復 更多評論
2005-12-24 15:34 by
建筑是一次性的,軟件是演變的。一個特定的建筑是一個時代的象征,它不僅不能變,人們還希望它能以老樣子一直存在下去。我們的故宮,長城。總不能把故宮再利用成某某步行街,某某大賣場。軟件的關鍵就在這個軟字上了。考驗你的真是軟件的彈性上。
# re: 架構師不是建筑師 回復 更多評論
2006-06-02 11:34 by
軟件架構師與建筑架構師可以類比,它們之間確有相通之處,類比來理解有好處;當然也有不同之處,等同起來肯定是錯誤的,也沒人會真這樣等同理解;也許類比會引起一些誤解,只要澄清和避免就好了,你的觀點不用這么極端。
該文提出的建筑與軟件的不同點,體現在以下方面:
1)建筑主要是靜態結構實體,軟件是靜態結構與動態行為的結合體。
2)建筑是一次性的,可擴展性不強,建筑完成后只需維護工作,可能千年以前的建筑至今沒多大變化;軟件是不斷進化的,可擴展性強,在架構不變的情況下,還可以對其修補,添加插件增強功能,不斷進行升級換代,最新版相比幾年前的版本可能面目全非。
3)在標準上,軟件缺乏建筑領域眾多的質量標準,使得軟件的質量保證較難檢驗。
4)在需求分析上,軟件相比建筑較難實施。建筑的需求通常有定量的數據和規范的說明;軟件尤其是應用軟件,強烈依賴于用戶個性化的需求。應用軟件的需求分析基本上等同于對用戶的行為進行建模。而用戶行為常常缺乏嚴格的定義,沒有清晰的描述,給軟件的設計與開發增加了難度。
以上是不同點的總結。上述四點中,第一點反映了建筑與軟件內在邏輯上的不同;第二點反映了兩者在完成后的發展的不同;第三點反映了兩者在質量保證標準上的不同;第四點反映了兩者在需求分析上的不同。這些不同點是值得注意的地方,但在工程方法論上,軟件可以從建筑領域中借鑒很多。
作者與該文觀點相悖的是,對UI的追求,建筑和軟件在理念上是一致的。在滿足質量的前提下,為什么不能提供給使用者更友好更美觀的外觀呢。地球上眾多經典建筑無不具有極具特色,飽含藝術性的特點;眾多經典軟件的界面也往往得到用戶真心實意的贊美。我們要避免的是,不要金玉其外,敗絮其中,要把軟件功能的質量放在第一位,在高質量地實現軟件功能的同時也追求最友好最優美的用戶使用界面。
事實上,建筑與軟件仍具有大量的相通之處,此處不一一贅述。讀過《設計模式》的朋友可以發現,GOF從建筑領域得到了大量有益的啟示。另外,建議大家讀一下《建筑的永恒之道》,相信此書會帶給你一些有益的思考。