canonical

    系統(tǒng)架構(gòu)通俗的說起來就是系統(tǒng)的結(jié)構(gòu)組織方式.原則上說, 架構(gòu)只有好壞之分,而不存在有無的問題. 軟件的體系架構(gòu)可以直接體現(xiàn)為代碼的類結(jié)構(gòu), 也可以表現(xiàn)為文檔性的編碼規(guī)范和全局約定等. 如果軟件架構(gòu)中能夠抽象出一些穩(wěn)定的元素, 那我們就可能得到一些所謂的框架代碼. 一般業(yè)務架構(gòu)是很難重用的, 目前常見的框架代碼所描述的多半是與業(yè)務無關的技術架構(gòu).
    
    良好的系統(tǒng)架構(gòu)應該體現(xiàn)出應用本身的結(jié)構(gòu)要求. 所謂各個為自己, 架構(gòu)為大家. 只要各個局部符合規(guī)格, 應該由架構(gòu)負責在合適的時刻按照合適的方式把它們組裝在一些. 一個良好的架構(gòu)中, 應該很少出現(xiàn)結(jié)構(gòu)性的if語句, 不需要應用代碼自己通過動態(tài)判斷來定義某個特殊的觸發(fā)時刻. 架構(gòu)是一種規(guī)范, 當然也就是一種局限. 架構(gòu)的可退化性是非常重要的, 否則一旦出現(xiàn)抽象泄露, 需要超出原有架構(gòu)設計做出編碼補充的時候, 往往無法將代碼自然的融入原有的框架結(jié)構(gòu), 則整個框架出現(xiàn)大面積的失效情況. 而有的時候更糟糕的情況是一些關鍵性的資源處在原有技術架構(gòu)的私有控制之中, 我們?yōu)榱丝朔軜?gòu)限制不得不采用各種trick來hack原有框架, 造成錯誤的累加和傳播, 而補丁的補丁是最難維護的.

    架構(gòu)問題并不是一成不變的. 在一些情形下無關緊要的問題在另一種情形下可能會成為災難性的架構(gòu)問題. 例如在多層B/S架構(gòu)下, 如果現(xiàn)在要求為每一個表增加一個對應的歷史表, 并對其進行查看和維護操作. 為了最大限度的重用代碼, 這要求我們的多層結(jié)構(gòu)中的每一層都能夠參數(shù)化, 這樣我們才能用同樣的代碼處理不同的數(shù)據(jù)表. 如果我們的money很足, 小弟夠多, 有足夠的人月砸上去, 那么我們完全可以把業(yè)務表和歷史表分開處理, 但如果反之,我們就會遇到一個典型的架構(gòu)問題.

    架構(gòu)師未必有自己的框架, 因為設計不等價于創(chuàng)造, 架構(gòu)師只要知道如何把系統(tǒng)中的各種元素按照可行的方式組裝在一起就可以了. 但是一個架構(gòu)設計是非常依賴于我們所能采用的技術手段的, 當現(xiàn)有各種可用的技術元素都無法滿足我們的需求的時候, 某些架構(gòu)師可能會選擇創(chuàng)造一種技術元素. 當然, 創(chuàng)造是艱難的, 它所要求的甚至是不同的技能. Sun的Green項目創(chuàng)造了java語言, 從而開啟了一個偉大的時代, 這絕對不會是大多數(shù)架構(gòu)設計師的選擇(有趣的是,Green項目本身失敗了). EJB現(xiàn)在還有多少人在真正使用, 想想當年多少架構(gòu)師在吹噓這些東西. 他們對于技術的把握真的就那么幼稚嗎? 架構(gòu)設計并不是憑空出現(xiàn)的, 當時可選的東西就是如此, 而spring和hibernate這些都不屬于架構(gòu)設計本身的內(nèi)容.它們是一種創(chuàng)造.
    
    架構(gòu)師未必是團隊的領導者. 確實,他的工作類似于編劇, 負責執(zhí)行的一般是導演. 事實上,一個建筑設計師是極少直接領導一個工程隊的.架構(gòu)師也未必比高級程序員要高明, 他們負責的是不同的內(nèi)容. 至于產(chǎn)品的"商標及商標的相關元素"和"技術市場架構(gòu)"等也不屬于架構(gòu)師的工作范疇, 他不能去搶產(chǎn)品經(jīng)理的飯碗. 當然,在國內(nèi)的現(xiàn)實情況下, 很多所謂的架構(gòu)師所做的最重要的工作可能是公關工作, 向客戶秀出所謂的理念, 與實際開發(fā)是不搭嘎的.     
    
    理論上說, 架構(gòu)師可以不是編程的強者, 也可以不決定一些具體數(shù)據(jù)結(jié)構(gòu)的選擇, 但他不能不了解各種技術抉擇潛在的影響. 這就如同一個建筑設計師可以不精通工程力學,但是他不能愚蠢到藐視重力, 設計出倒三角式的大廈. 與建筑不同的是, 在軟件中我們所面臨的不是一種"凝固的藝術", 我們無法以完全靜態(tài)的方式理解代碼,而必須在頭腦中把它們運行起來. 架構(gòu)師應該寫下一些實際的代碼, 以檢驗各個接口的可配合性并獲得對于代碼結(jié)構(gòu)的直接感覺. 實際上, 按照現(xiàn)在軟件業(yè)的成熟度, 一般我們無法實現(xiàn)建筑中建筑設計師與土木工程師的分工, 很多時候軟件架構(gòu)師都需要直接面對實現(xiàn)的細節(jié). 如果組內(nèi)缺乏非常強悍的coder, 有編程能力的架構(gòu)師親自操刀實現(xiàn)關鍵性代碼的時候也是很多的.

    架構(gòu)師必須有經(jīng)驗, 但他所依賴的不能只是經(jīng)驗. 只要算一算架構(gòu)師的年紀, 就會知道以他們在這個世界上的存在時間, 并不足以使得他們經(jīng)歷各種技術細節(jié). 架構(gòu)設計更多的是依賴我們對于系統(tǒng)結(jié)構(gòu)原理的理解, 而經(jīng)驗可以讓我們規(guī)避那些原理失效的地方(例如系統(tǒng)級bug). 君子非異能也, 善假于物也. 很多時候,我們更應該從有經(jīng)驗的朋友或者技術支持那里搜集技術細節(jié), 以確保它們能夠滿足我們在架構(gòu)上的原理性需求. Know Why而不僅僅是Know How是非常重要的. 一個農(nóng)民發(fā)明家也許可以得到某個巧妙的機械設計, 但是沒有系統(tǒng)的掌握工程力學, 他們是無法去開發(fā)精密的導彈控制系統(tǒng)的.當然, 軟件開發(fā)還處在非常原始的階段, 掌握一些設計原理和設計模式多半也不過是五十步笑百步而已, 經(jīng)驗的地位是無可替代的.

    架構(gòu)師不是預言家. 在多變的業(yè)務環(huán)境中, 架構(gòu)師的目標不應該是預測到所有的變化可能, 并把它們表達到系統(tǒng)架構(gòu)中. 這個世界上不乏一些耗資數(shù)十億,設計三四年,但最終每個談到它的人都要說一句shit的產(chǎn)品開發(fā)項目. 架構(gòu)設計所能做到的最好的程度是自然的標注出系統(tǒng)的結(jié)構(gòu)邊界,成功的delay各種技術抉擇.

    架構(gòu)師不是超人, 他所考慮的東西也許要遠一些, 所需要平衡的利益也許要多一些, 但是單獨一個人是無法對整個產(chǎn)品或者項目的成敗負責的. 如果ThoughtWorks的Martin Follower來處理國內(nèi)的某些項目, 我估計他會死得很難看.架構(gòu)師也是人, 也會犯錯誤,甚至是很低級的錯誤, 而每個人都會有一些獨特的想法. 經(jīng)歷的多了, 你就會回歸到終極的認識, 一切都只是浮云, 只有money才是硬道理.