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