Posted on 2005-12-18 17:35
canonical 閱讀(3762)
評論(8) 編輯 收藏 所屬分類:
設計理論
系統架構通俗的說起來就是系統的結構組織方式.原則上說, 架構只有好壞之分,而不存在有無的問題.
軟件的體系架構可以直接體現為代碼的類結構, 也可以表現為文檔性的編碼規范和全局約定等. 如果軟件架構中能夠抽象出一些穩定的元素,
那我們就可能得到一些所謂的框架代碼. 一般業務架構是很難重用的, 目前常見的框架代碼所描述的多半是與業務無關的技術架構.
良好的系統架構應該體現出應用本身的結構要求. 所謂各個為自己, 架構為大家. 只要各個局部符合規格,
應該由架構負責在合適的時刻按照合適的方式把它們組裝在一些. 一個良好的架構中, 應該很少出現結構性的if語句,
不需要應用代碼自己通過動態判斷來定義某個特殊的觸發時刻. 架構是一種規范, 當然也就是一種局限. 架構的可退化性是非常重要的,
否則一旦出現抽象泄露, 需要超出原有架構設計做出編碼補充的時候, 往往無法將代碼自然的融入原有的框架結構, 則整個框架出現大面積的失效情況.
而有的時候更糟糕的情況是一些關鍵性的資源處在原有技術架構的私有控制之中, 我們為了克服架構限制不得不采用各種trick來hack原有框架,
造成錯誤的累加和傳播, 而補丁的補丁是最難維護的.
架構問題并不是一成不變的. 在一些情形下無關緊要的問題在另一種情形下可能會成為災難性的架構問題.
例如在多層B/S架構下, 如果現在要求為每一個表增加一個對應的歷史表, 并對其進行查看和維護操作. 為了最大限度的重用代碼,
這要求我們的多層結構中的每一層都能夠參數化, 這樣我們才能用同樣的代碼處理不同的數據表. 如果我們的money很足, 小弟夠多,
有足夠的人月砸上去, 那么我們完全可以把業務表和歷史表分開處理, 但如果反之,我們就會遇到一個典型的架構問題.
架構師未必有自己的框架, 因為設計不等價于創造,
架構師只要知道如何把系統中的各種元素按照可行的方式組裝在一起就可以了. 但是一個架構設計是非常依賴于我們所能采用的技術手段的,
當現有各種可用的技術元素都無法滿足我們的需求的時候, 某些架構師可能會選擇創造一種技術元素. 當然, 創造是艱難的,
它所要求的甚至是不同的技能. Sun的Green項目創造了java語言, 從而開啟了一個偉大的時代,
這絕對不會是大多數架構設計師的選擇(有趣的是,Green項目本身失敗了). EJB現在還有多少人在真正使用,
想想當年多少架構師在吹噓這些東西. 他們對于技術的把握真的就那么幼稚嗎? 架構設計并不是憑空出現的, 當時可選的東西就是如此,
而spring和hibernate這些都不屬于架構設計本身的內容.它們是一種創造.
架構師未必是團隊的領導者. 確實,他的工作類似于編劇, 負責執行的一般是導演.
事實上,一個建筑設計師是極少直接領導一個工程隊的.架構師也未必比高級程序員要高明, 他們負責的是不同的內容.
至于產品的"商標及商標的相關元素"和"技術市場架構"等也不屬于架構師的工作范疇, 他不能去搶產品經理的飯碗. 當然,在國內的現實情況下,
很多所謂的架構師所做的最重要的工作可能是公關工作, 向客戶秀出所謂的理念, 與實際開發是不搭嘎的.
理論上說, 架構師可以不是編程的強者, 也可以不決定一些具體數據結構的選擇,
但他不能不了解各種技術抉擇潛在的影響. 這就如同一個建筑設計師可以不精通工程力學,但是他不能愚蠢到藐視重力, 設計出倒三角式的大廈.
與建筑不同的是, 在軟件中我們所面臨的不是一種"凝固的藝術", 我們無法以完全靜態的方式理解代碼,而必須在頭腦中把它們運行起來.
架構師應該寫下一些實際的代碼, 以檢驗各個接口的可配合性并獲得對于代碼結構的直接感覺. 實際上, 按照現在軟件業的成熟度,
一般我們無法實現建筑中建筑設計師與土木工程師的分工, 很多時候軟件架構師都需要直接面對實現的細節. 如果組內缺乏非常強悍的coder,
有編程能力的架構師親自操刀實現關鍵性代碼的時候也是很多的.
架構師必須有經驗, 但他所依賴的不能只是經驗. 只要算一算架構師的年紀,
就會知道以他們在這個世界上的存在時間, 并不足以使得他們經歷各種技術細節. 架構設計更多的是依賴我們對于系統結構原理的理解,
而經驗可以讓我們規避那些原理失效的地方(例如系統級bug). 君子非異能也, 善假于物也.
很多時候,我們更應該從有經驗的朋友或者技術支持那里搜集技術細節, 以確保它們能夠滿足我們在架構上的原理性需求. Know
Why而不僅僅是Know How是非常重要的. 一個農民發明家也許可以得到某個巧妙的機械設計, 但是沒有系統的掌握工程力學,
他們是無法去開發精密的導彈控制系統的.當然, 軟件開發還處在非常原始的階段, 掌握一些設計原理和設計模式多半也不過是五十步笑百步而已,
經驗的地位是無可替代的.
架構師不是預言家. 在多變的業務環境中, 架構師的目標不應該是預測到所有的變化可能,
并把它們表達到系統架構中. 這個世界上不乏一些耗資數十億,設計三四年,但最終每個談到它的人都要說一句shit的產品開發項目.
架構設計所能做到的最好的程度是自然的標注出系統的結構邊界,成功的delay各種技術抉擇.
架構師不是超人, 他所考慮的東西也許要遠一些, 所需要平衡的利益也許要多一些,
但是單獨一個人是無法對整個產品或者項目的成敗負責的. 如果ThoughtWorks的Martin Follower來處理國內的某些項目,
我估計他會死得很難看.架構師也是人, 也會犯錯誤,甚至是很低級的錯誤, 而每個人都會有一些獨特的想法. 經歷的多了, 你就會回歸到終極的認識,
一切都只是浮云, 只有money才是硬道理.