|
軟件架構(gòu)要設(shè)計(jì)到什么程度？
本文節(jié)錄溫昱先生《軟件架構(gòu)設(shè)計(jì)》第8章 軟件架構(gòu)要做到什么程度，并將自己的理解在節(jié)錄后做出描述。希望節(jié)錄部分能給大家?guī)?lái)收獲和感悟。并對(duì)我的理解部分提出建議和想法。
OK,讓我們開(kāi)始吧.解決軟件架構(gòu)到底要設(shè)計(jì)到什么程度?
* 首先，對(duì)軟件架構(gòu)的設(shè)計(jì)程度問(wèn)題展開(kāi)探討，得出基本結(jié)論。從對(duì)“分而治之”的討論入手，說(shuō)明軟件架構(gòu)是團(tuán)隊(duì)開(kāi)發(fā)的基礎(chǔ)，從而，軟件架構(gòu)必須設(shè)計(jì)到“能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制”的程度;
* 之后，從問(wèn)題入手，認(rèn)識(shí)高來(lái)高去式架構(gòu)設(shè)計(jì)的“癥狀”。主要分析實(shí)際工作中常見(jiàn)的架構(gòu)設(shè)計(jì)不足的幾種表現(xiàn)，找到要解決的問(wèn)題;
* 然后，說(shuō)明如何解決架構(gòu)設(shè)計(jì)高來(lái)高去、指導(dǎo)不足的問(wèn)題;
* 最后，結(jié)合案例，說(shuō)明如何一步步地將架構(gòu)設(shè)計(jì)落實(shí)到實(shí)處。
-------------------------------------------------------------------------------------
8.1 軟件架構(gòu)要設(shè)計(jì)到什么程度
軟件架構(gòu)必須設(shè)計(jì)到“能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制”的程度。
8.1.1 分而治之的兩種方式
為什么要分而治之?簡(jiǎn)單說(shuō)，就是問(wèn)題太復(fù)雜了，超出了人們能夠“一蹴而就”的范圍。
面對(duì)一個(gè)復(fù)雜的問(wèn)題，我們?nèi)绾芜M(jìn)行分而治之呢?策略有二：
一、先不把問(wèn)題研究得那么深，那么細(xì)，淺嘗輒止，見(jiàn)好就收。這種分而治之的方式稱為“按問(wèn)題深度分而治之”。
二、先不研究整個(gè)問(wèn)題，而是研究問(wèn)題的一部分，分割問(wèn)題，各個(gè)擊破。這種分而治之的方式稱為“按問(wèn)題廣度分而治之”。
例如：
接口和實(shí)現(xiàn)分離，就是“按問(wèn)題深度分而治之”的一個(gè)例子。在架構(gòu)設(shè)計(jì)之時(shí)，我們往往無(wú)需深入到一個(gè)子系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)中去，而是分而治之，先確定該子系統(tǒng)的接口。接口的設(shè)計(jì)在整個(gè)架構(gòu)設(shè)計(jì)中占有重要地位，它定義了一個(gè)子系統(tǒng)為其他子系統(tǒng)所提供服務(wù)的契約。軟件架構(gòu)通過(guò)明確每個(gè)子系統(tǒng)所要實(shí)現(xiàn)的接口及所要調(diào)用的接口，為我們展現(xiàn)了一個(gè)軟件系統(tǒng)如何分割為多個(gè)相互協(xié)作的子系統(tǒng)。
“按問(wèn)題廣度分而治之”的例子也很常見(jiàn)，比如展現(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層的開(kāi)發(fā)往往需要不同的技術(shù),可以分派給不同的小組承擔(dān)等,不一而足。
8.1.2 架構(gòu)設(shè)計(jì)與詳細(xì)設(shè)計(jì)
隨著軟件設(shè)計(jì)工作越來(lái)越復(fù)雜，將架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)分離已成為普遍的做法。Garlan就曾指出：“隨著軟件的規(guī)模和復(fù)雜度增加，算法和數(shù)據(jù)結(jié)構(gòu)以外的設(shè)計(jì)問(wèn)題就會(huì)出現(xiàn)：設(shè)計(jì)和制定系統(tǒng)整體結(jié)構(gòu)將成為新的一類問(wèn)題......這是軟件架構(gòu)層次的設(shè)計(jì)�！�
將設(shè)計(jì)分為架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)，是對(duì)“按問(wèn)題深度分而治之”思想的運(yùn)用。
* 所謂架構(gòu)設(shè)計(jì)，就是關(guān)于如何構(gòu)建軟件的一些最重要的設(shè)計(jì)決策，這些決策往往是圍繞將系統(tǒng)分為哪些部分，各部分之間如何交互展開(kāi)的;
* 而詳細(xì)設(shè)計(jì)針對(duì)每個(gè)部分的內(nèi)部進(jìn)行設(shè)計(jì)。
可以這么說(shuō)，軟件架構(gòu)設(shè)計(jì)應(yīng)當(dāng)解決的是全局性的、涉及不同“局部”之間交互的設(shè)計(jì)問(wèn)題，而不同“局部”的設(shè)計(jì)由后續(xù)的詳細(xì)設(shè)計(jì)負(fù)責(zé)。于是，在軟件架構(gòu)所提供的“合作契約”的指導(dǎo)之下，眾多局部問(wèn)題被很好地“按問(wèn)題廣度分而治之”了----對(duì)局部的設(shè)計(jì)完全可以并行進(jìn)行。
總之，這種先確定軟件架構(gòu)，而后基于軟件架構(gòu)進(jìn)行并行開(kāi)發(fā)的做法，綜合利用了兩種分而治之的方法，利于控制復(fù)雜性，提高開(kāi)發(fā)效率。這是一種值得推崇的開(kāi)發(fā)方式，常被稱為“以架構(gòu)為中心的開(kāi)發(fā)方法”。
8.1.3 軟件架構(gòu)是團(tuán)隊(duì)開(kāi)發(fā)的基礎(chǔ)
正如大家所看到的，因?yàn)檐浖兊迷絹?lái)越復(fù)雜了，所以單兵作戰(zhàn)不再是普遍的軟件開(kāi)發(fā)方式，取而代之的是團(tuán)隊(duì)開(kāi)發(fā)：而團(tuán)隊(duì)開(kāi)發(fā)又反過(guò)來(lái)使軟件開(kāi)發(fā)更加復(fù)雜，因?yàn)楝F(xiàn)在不僅僅有技術(shù)復(fù)雜性的問(wèn)題，還有管理復(fù)雜性的問(wèn)題。
面對(duì)“技術(shù)復(fù)雜性”和“管理復(fù)雜性”這樣的雙重困難，以架構(gòu)為中心的開(kāi)發(fā)方法是有效的途徑：
* 一方面，軟件架構(gòu)從大局著手，就技術(shù)方面的重大問(wèn)題作出決策，構(gòu)造一個(gè)具有一定抽象層次的解決方案，而不是將所有細(xì)節(jié)統(tǒng)統(tǒng)展開(kāi)，從而有效地控制了“技術(shù)復(fù)雜性”�？梢钥闯�，軟件架構(gòu)這一步?jīng)]有“把問(wèn)題研究那么深、那么細(xì)”，屬于“按問(wèn)題深度分而治之”。對(duì)此，Ivar Jacobson給我們提供了非常形象的說(shuō)法，“軟件系統(tǒng)的架構(gòu)涵蓋了整個(gè)系統(tǒng)，盡管架構(gòu)的有些部分可能只有'一寸深'”;
* 另一方面，有了軟件架構(gòu)設(shè)計(jì)方案之后呢?因?yàn)椤凹軜?gòu)中包含了關(guān)于各元素應(yīng)如何彼此相關(guān)的信息”，從而可以把不同模塊分配給不同小組分頭開(kāi)發(fā)，而軟件架構(gòu)設(shè)計(jì)方案在這些小組中間扮演“橋梁”和“合作契約”的作用。每個(gè)小組的工作覆蓋了“整個(gè)問(wèn)題的一部分”，各小組之間可以互相獨(dú)立地進(jìn)行并行工作，這種“分割問(wèn)題，各個(gè)擊破”的策略，屬于“按問(wèn)題廣度分而治之”。
這兩方面是相輔相成的關(guān)系。具體而言，正因?yàn)檐浖軜?gòu)是大規(guī)模開(kāi)發(fā)的基礎(chǔ)，所以架構(gòu)中應(yīng)包含軟件系統(tǒng)的各元素如何彼此相關(guān)的設(shè)計(jì)決策;也正是因?yàn)檐浖軜?gòu)中包含了軟件系統(tǒng)如何組織等關(guān)鍵決策，才使得它能夠成為大規(guī)模開(kāi)發(fā)的基礎(chǔ)。
這樣一來(lái)，模塊的技術(shù)細(xì)節(jié)被局部化到了小組內(nèi)部，內(nèi)部的細(xì)節(jié)不會(huì)成為小組間協(xié)作溝通的主要內(nèi)容，理順了溝通的層次。另外，對(duì)“人盡其才”也有好處，不同小組的成員需要精通的技術(shù)各不相同。例如，用戶界面層的開(kāi)發(fā)小組需要了解將使用的用戶界面工具包;數(shù)據(jù)管理層的并發(fā)小組需要熟悉相關(guān)的數(shù)據(jù)庫(kù)、持久工具或者使用的文件系統(tǒng);系統(tǒng)交互層的開(kāi)發(fā)小組需要了解通訊和用到的中間件產(chǎn)品等。
由此可見(jiàn)，軟件架構(gòu)為開(kāi)展系統(tǒng)化的團(tuán)隊(duì)開(kāi)發(fā)奠定了基礎(chǔ)，為解決“管理復(fù)雜性”提供了有力的支持。對(duì)此Barry Boehm曾經(jīng)明確指出，“如果一個(gè)項(xiàng)目的系統(tǒng)架構(gòu)(包括理論基礎(chǔ))尚未確定，就不應(yīng)該進(jìn)行此系統(tǒng)的全面開(kāi)發(fā)�！�
8.1.4 架構(gòu)要進(jìn)行到什么程度
既然軟件架構(gòu)是團(tuán)隊(duì)開(kāi)發(fā)的基礎(chǔ)，那么它就應(yīng)該比較明確地規(guī)定后期分頭開(kāi)發(fā)所必須的公共性的設(shè)計(jì)約定，從而為分頭開(kāi)發(fā)提供足夠的指導(dǎo)和限制。
另一方面，具體的架構(gòu)設(shè)計(jì)程度還會(huì)因軟件項(xiàng)目的不同而不同，例如航空航天領(lǐng)域中的軟件系統(tǒng)對(duì)系統(tǒng)可靠性要求非常高，這種情況下對(duì)架構(gòu)設(shè)計(jì)詳細(xì)程度的要求也會(huì)比較高;同時(shí)，架構(gòu)設(shè)計(jì)的程度也會(huì)受團(tuán)隊(duì)具體情況的影響，有類似項(xiàng)目經(jīng)驗(yàn)的團(tuán)隊(duì)可以適當(dāng)放寬標(biāo)準(zhǔn)，而分布團(tuán)隊(duì)或者涉及外包的情況則應(yīng)更強(qiáng)調(diào)架構(gòu)的明確性。
架構(gòu)設(shè)計(jì)對(duì)軟件的不同部分的設(shè)計(jì)程度并不是整齊劃一的。例如，通信機(jī)制、持久化機(jī)制和消息機(jī)制等對(duì)應(yīng)的公共模塊，在架構(gòu)設(shè)計(jì)時(shí)會(huì)設(shè)計(jì)得比較深入，因?yàn)樗鼈冚^多地涉及軟件的不同部分之間的交互;而具體的業(yè)務(wù)功能模塊在架構(gòu)設(shè)計(jì)中往往設(shè)計(jì)程度不深。
總之，關(guān)于軟件架構(gòu)到底要設(shè)計(jì)到什么程度，可以歸納為兩句話：
* 由于項(xiàng)目的不同、開(kāi)發(fā)團(tuán)隊(duì)情況的不同，軟件架構(gòu)的設(shè)計(jì)程度會(huì)有不同;
* 軟件架構(gòu)應(yīng)當(dāng)為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制。
8.2 高來(lái)高去式架構(gòu)設(shè)計(jì)的癥狀
所謂“高來(lái)高去式架構(gòu)設(shè)計(jì)”，是指不能為開(kāi)發(fā)人員提供足夠的指導(dǎo)和限制的那種架構(gòu)設(shè)計(jì)方案。高來(lái)高去式架構(gòu)設(shè)計(jì)現(xiàn)象極為普遍，它可能帶來(lái)的危害包括：
* 缺少來(lái)自架構(gòu)的足夠的指導(dǎo)和限制，開(kāi)發(fā)人員在進(jìn)入分頭開(kāi)發(fā)階段之后會(huì)碰到很多問(wèn)題，并且容易造成管理混亂，溝通和協(xié)作效率低；
* 對(duì)軟件質(zhì)量非常關(guān)鍵的全局性設(shè)計(jì)決定被拖延到分頭開(kāi)發(fā)期間草率決定，嚴(yán)重降低了軟件產(chǎn)品質(zhì)量；
* 沒(méi)有完成化解重大技術(shù)風(fēng)險(xiǎn)的職責(zé)，可能造成整個(gè)項(xiàng)目失�。�
* 團(tuán)隊(duì)成員對(duì)架構(gòu)師意見(jiàn)很大，團(tuán)隊(duì)士氣受到打擊。
“發(fā)現(xiàn)問(wèn)題是解決問(wèn)題的一半”，下面為高來(lái)高去問(wèn)題歸類。
癥狀一：缺失重要架構(gòu)視圖。為了給團(tuán)隊(duì)的不同角色提供切實(shí)的指導(dǎo)，軟件架構(gòu)師應(yīng)從不同視圖進(jìn)行架構(gòu)的設(shè)計(jì)和歸檔。如果忽視了在某重要架構(gòu)視圖方面的設(shè)計(jì)，就會(huì)遺漏重要設(shè)計(jì)決策，具體的開(kāi)發(fā)工作將會(huì)陷入缺乏應(yīng)有指導(dǎo)和限制的困境。
癥狀二：淺嘗輒止、不夠深入。架構(gòu)設(shè)計(jì)方案過(guò)于籠統(tǒng)，基本還停留在概念性架構(gòu)的層面，沒(méi)有提供明確的技術(shù)草圖。于是，全局性的設(shè)計(jì)決策最后由具體開(kāi)發(fā)人員從局部視角考慮并確定下來(lái)，造成技術(shù)和管理上的種種問(wèn)題。
癥狀三：名不副實(shí)的分層架構(gòu)。通過(guò)分層將架構(gòu)系統(tǒng)模塊之后，就迫不及待地喊出“分層架構(gòu)”的口號(hào)，對(duì)各層之間交互接口和交互機(jī)制的設(shè)計(jì)嚴(yán)重不足。
8.2.1 缺失重要架構(gòu)視圖
如你所知，由于角色和分工不同,整個(gè)軟件團(tuán)隊(duì)以及客戶等涉及各自需要掌握的技術(shù)或技能存在很大差異。這就使得他們?yōu)榱送瓿筛髯缘墓ぷ�，需要了解整套軟件架�?gòu)決策的不同子集�；诙嘀匾晥D開(kāi)展軟件架構(gòu)設(shè)計(jì)的方法，就能夠解決上述問(wèn)題。
實(shí)際經(jīng)驗(yàn)表明，越是復(fù)雜的系統(tǒng)，越是需要從多個(gè)方面進(jìn)行架構(gòu)設(shè)計(jì)，這親才能把問(wèn)題研究和表達(dá)清楚。Grady Booch 在其著作《UML用戶指南》中指出：“如果選擇視圖的工作沒(méi)有做好，或者以犧牲其他視圖為代價(jià)只注重一個(gè)視圖，就會(huì)冒掩蓋問(wèn)題以及延誤解決問(wèn)題（這里的問(wèn)題是指那些最終會(huì)導(dǎo)致失敗的問(wèn)題）的風(fēng)險(xiǎn)。”
為不同的軟件系統(tǒng)進(jìn)行架構(gòu)設(shè)計(jì)時(shí)，對(duì)不同的架構(gòu)視圖的重視程度并不相同。例如，用于反映軟件系統(tǒng)運(yùn)行時(shí)的動(dòng)態(tài)結(jié)構(gòu)，以及組成軟件系統(tǒng)的目標(biāo)程序如何部署到硬件上的物理架構(gòu)視圖，對(duì)于分布式系統(tǒng)的架構(gòu)設(shè)計(jì)來(lái)說(shuō)是必不可少的。再例如，現(xiàn)在大量采用現(xiàn)成框架（比如眾多開(kāi)源框架）進(jìn)行開(kāi)發(fā)的軟件系統(tǒng)越來(lái)越多了，這時(shí)開(kāi)發(fā)架構(gòu)視圖就顯得極為必要----開(kāi)發(fā)架構(gòu)關(guān)注程序包，不僅包括要編寫(xiě)的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架和類庫(kù)，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。
“缺失重要架構(gòu)視圖”的一種表現(xiàn)是，認(rèn)為軟件架構(gòu)設(shè)計(jì)完全是用例驅(qū)動(dòng)的，片面強(qiáng)調(diào)用例描述的功能需求。此時(shí)，架構(gòu)設(shè)計(jì)對(duì)非功能需求關(guān)注不夠，既沒(méi)有深入設(shè)計(jì)軟件的運(yùn)行架構(gòu)（對(duì)性能、可伸縮性、持續(xù)可用性等運(yùn)行期質(zhì)量屬性很重要），也沒(méi)有深入設(shè)計(jì)軟件的開(kāi)發(fā)架構(gòu)（對(duì)可擴(kuò)展性、可重用性、可測(cè)試性和可移植性等開(kāi)發(fā)期質(zhì)量屬性很重要）。軟件開(kāi)發(fā)人員會(huì)感覺(jué)到架構(gòu)設(shè)計(jì)方案離他們很“遙遠(yuǎn)”，既沒(méi)有說(shuō)明程序包的組織結(jié)構(gòu)，也沒(méi)有明確架構(gòu)設(shè)計(jì)中的關(guān)鍵抽象和所采用框架的關(guān)系，等等。
8.2.2 淺嘗輒止、不夠深入
此時(shí)，架構(gòu)設(shè)計(jì)方案往往過(guò)于籠統(tǒng)，基本還停留在概念性架構(gòu)的層面，沒(méi)有提供明確的技術(shù)藍(lán)圖。
概念性架構(gòu)雖說(shuō)不用，但“不用”不代表“夠用”。概念性架構(gòu)對(duì)開(kāi)發(fā)人員的指導(dǎo)和限制是不夠的。為了化解高技術(shù)風(fēng)險(xiǎn)，證明技術(shù)上的可行性，必須充分考慮技術(shù)，例如關(guān)鍵機(jī)制、核心技術(shù)和第三方框架都應(yīng)明確。
另外，投票或售前演示級(jí)別的架構(gòu)方案對(duì)市場(chǎng)活動(dòng)或許早夠了，但對(duì)實(shí)際的開(kāi)發(fā)卻顯得過(guò)于籠統(tǒng)。比如，對(duì)如何達(dá)到高安全性目標(biāo)，僅提出了采用傳輸加密、存儲(chǔ)加密和數(shù)字簽名等技術(shù)，但并未明確這些技術(shù)如何影響軟件系統(tǒng)的其他部分，它們是否通過(guò)統(tǒng)一的服務(wù)接口封裝，別的模塊是直接調(diào)用它們還是利用AOP機(jī)制松耦合地觸發(fā)等問(wèn)題。同樣，為了達(dá)到高可擴(kuò)展性的要求，輕描淡寫(xiě)地“采用模塊化設(shè)計(jì)”對(duì)實(shí)際開(kāi)發(fā)也過(guò)于籠統(tǒng)。
無(wú)論上述的哪一種情況，它們?cè)斐傻奈：Χ际窍嗤�；架�?gòu)設(shè)計(jì)階段遺漏了全局性的設(shè)計(jì)決策，到了大規(guī)模開(kāi)發(fā)實(shí)際階段，這些設(shè)計(jì)決策往往被具體開(kāi)發(fā)人員從局部視角考慮并確定下來(lái)，如此一來(lái)，就會(huì)在模塊協(xié)作方面出現(xiàn)問(wèn)題，而且公共的服務(wù)模塊也未能被識(shí)別出來(lái)。
8.2.3 名不副實(shí)的分層架構(gòu)
“名不副實(shí)的分層架構(gòu)”可以認(rèn)為是“淺嘗輒止、不夠深入”式架構(gòu)設(shè)計(jì)的一種具體表現(xiàn)，但由于分層架構(gòu)的應(yīng)用太廣泛了，幾乎無(wú)處不在，因此我們把它單獨(dú)列出并著重討論。
“名不副實(shí)的分層架構(gòu)”是指那些號(hào)稱采用分層架構(gòu)，卻僅用分層來(lái)進(jìn)行職責(zé)劃分，而沒(méi)有規(guī)劃層次之間的交互接口和交互機(jī)制的情況，而經(jīng)典的分層架構(gòu)屬于“調(diào)用 - 返回”式的架構(gòu)模式，和“主程序 - 子程序”架構(gòu)模式同屬一種類型�？梢哉f(shuō)，缺失交互接口和交互機(jī)制的分層架構(gòu)中，其中“層”已退化成籠統(tǒng)意義上的“職責(zé)模塊”了。
很多道理是相通的。一個(gè)公司，它的組織結(jié)構(gòu)圖就掛在墻上----再清晰不過(guò)了，但公司的運(yùn)營(yíng)卻很混亂，這是為什么呢？來(lái)了任務(wù)、出了事情不清楚找哪個(gè)經(jīng)理，此謂接口不清；日常的匯報(bào)體系如何，突發(fā)事件如何處理也未明確，此謂機(jī)制不明。事實(shí)，這何嘗不是一種架構(gòu)不夠明確的表現(xiàn)呢？
對(duì)軟件系統(tǒng)也是同樣，而對(duì)缺失交互接口和交互機(jī)制的分層架構(gòu)，許多開(kāi)發(fā)人員依然得不到足夠明確的指導(dǎo)。
“名不副實(shí)的分層架構(gòu)”常見(jiàn)于各大報(bào)紙、各種市場(chǎng)材料。由于它們常冠以“總體架構(gòu)”等名稱出現(xiàn)，而不是實(shí)際上的“軟件架構(gòu)之冰山一角”，所以，有些沒(méi)有經(jīng)驗(yàn)的架構(gòu)師會(huì)誤認(rèn)為他們要設(shè)計(jì)的也是這種“高來(lái)高去式的軟件架構(gòu)”。
讓我們來(lái)重溫一下學(xué)生時(shí)代的“反證法”：
（1）假設(shè)，市場(chǎng)材料里的軟件架構(gòu)不是高來(lái)高去的，而是程度足夠深入的；
（2）那么，競(jìng)爭(zhēng)對(duì)手可以輕松地從市場(chǎng)材料里獲知你的核心技術(shù)；
（3）但是，是沒(méi)有人會(huì)把核心技術(shù)寫(xiě)到市場(chǎng)材料里公開(kāi)宣揚(yáng)的；
（4）因此，假設(shè)不成立，這意味著市場(chǎng)材料里的軟件架構(gòu)是高來(lái)高去的。
8.3 如何克服高來(lái)高去癥
批評(píng)應(yīng)有理有度。
可以這么說(shuō)，高來(lái)高去式的架構(gòu)本身并沒(méi)有錯(cuò)，它們往往屬于概念性架構(gòu)的范疇；一來(lái)它是對(duì)于市場(chǎng)宣傳來(lái)講已經(jīng)足夠了，二來(lái)它往往是循序漸進(jìn)進(jìn)行軟件架構(gòu)設(shè)計(jì)的良好起點(diǎn)。但是，如果停留在高來(lái)高去的架構(gòu)設(shè)計(jì)上止步不前。并以之作為最終的架構(gòu)設(shè)計(jì)方案，就會(huì)為后期開(kāi)發(fā)埋下重大風(fēng)險(xiǎn)。
將高來(lái)高去架構(gòu)設(shè)計(jì)的癥結(jié)、問(wèn)題與對(duì)策歸納如下：
-----------------------------------------------------
癥結(jié)：缺失重要架構(gòu)視圖
問(wèn)題：遺漏了對(duì)團(tuán)隊(duì)某些角色的指導(dǎo)
對(duì)策：針對(duì)遺漏的架構(gòu)視圖進(jìn)行設(shè)計(jì)
-----------------------------------------------------
癥結(jié)：淺嘗輒止、不夠深入
問(wèn)題：將重大技術(shù)風(fēng)險(xiǎn)遺留到后續(xù)開(kāi)發(fā)中
對(duì)策：設(shè)計(jì)決策須細(xì)化到和技術(shù)相關(guān)的層面
-----------------------------------------------------
癥結(jié)：名不副實(shí)的分層架構(gòu)
問(wèn)題：只用了分層架構(gòu)的分層概念來(lái)進(jìn)行職責(zé)劃分，沒(méi)有明確層次間的交互接口和交互機(jī)制。
對(duì)策：步步深入，明確各層之間的交互接口和交互機(jī)制。
8.4 網(wǎng)絡(luò)管理系統(tǒng)案例：如何將架構(gòu)設(shè)計(jì)落到實(shí)處
本節(jié)通過(guò)網(wǎng)絡(luò)管理系統(tǒng)架構(gòu)的“設(shè)計(jì)片斷”，演示如何將架構(gòu)落到實(shí)處的。
8.4.1 網(wǎng)管產(chǎn)品線的概念性架構(gòu)
本案例的網(wǎng)絡(luò)管理軟件是作為軟件產(chǎn)品線出現(xiàn)的，應(yīng)充分考慮多個(gè)產(chǎn)品之間的重用，建立共享的產(chǎn)品線架構(gòu)。
概念性架構(gòu)清晰定義了架構(gòu)的大局，并充分考慮了可移植性、可擴(kuò)展性、性能和版權(quán)等商業(yè)因素，以及較長(zhǎng)的生命周期等商業(yè)目標(biāo)這些因素，制定了相應(yīng)的高層設(shè)計(jì)決策。
但是，概念性架構(gòu)畢竟是概念性架構(gòu)，并不能為實(shí)際的開(kāi)發(fā)工作提供足夠的指導(dǎo)和限制。下面我們來(lái)進(jìn)行實(shí)際架構(gòu)層面的設(shè)計(jì)：篇幅有限，僅涉及識(shí)別功能塊、規(guī)劃功能塊的接口、明確功能塊之間的使用關(guān)系和使用機(jī)制等話題。
8.4.2 識(shí)別每一層中的功能模塊
抽象的職責(zé)最終必須由具體的功能模塊來(lái)承擔(dān)。我們接下來(lái)必須識(shí)別每一層中的功能模塊、以及各模塊承擔(dān)的職責(zé)。
8.4.3 明確各層之間的交互接口
在分層架構(gòu)中，下層對(duì)于上層應(yīng)盡量做到“黑盒”封裝。這樣一來(lái)，為每一層規(guī)劃接口就顯得非常重要。需要定義各層之間的交互接口。
8.4.4 明確各層之間的交互機(jī)制
更進(jìn)一步，有了接口，就可以明確交互機(jī)制。設(shè)計(jì)中采用的其實(shí)是一種基于方法調(diào)用的事件機(jī)制。
8.4.5 案例小結(jié)
我們沒(méi)有深入描述設(shè)計(jì)時(shí)所考慮的細(xì)節(jié)，而是著重描述了設(shè)計(jì)從不明確步步走向明確的過(guò)程。
我們還必須說(shuō)明，如何將架構(gòu)設(shè)計(jì)落到實(shí)處，其實(shí)根據(jù)架構(gòu)設(shè)計(jì)視圖的不同而不同。這是因?yàn)�，不同的軟件架�?gòu)視圖關(guān)注的對(duì)象不同（從模塊--到程序包--到進(jìn)程--到數(shù)據(jù)庫(kù)表--到物理節(jié)點(diǎn)等），從而設(shè)計(jì)手段也就會(huì)有差異。
8.5 總結(jié)與強(qiáng)調(diào)
本篇討論了一個(gè)對(duì)軟件開(kāi)發(fā)和管理都有深刻影響的問(wèn)題，軟件架構(gòu)要設(shè)計(jì)到什么程度？如果說(shuō)前面討論的架構(gòu)視圖關(guān)注了軟件架構(gòu)的橫向?qū)挾�，那么本章就是關(guān)注軟件架構(gòu)的縱向深度。
----------------------------------------------------------------------------------
個(gè)人理解部分：
看了本章后，有一種茅塞頓開(kāi)的感覺(jué)。對(duì)以下一些問(wèn)題有了更清晰的理解：
1. 在架構(gòu)方面，有可能是售前人員在做概要性架構(gòu)，也可能是軟件需求人員在做，作為眾開(kāi)發(fā)程序員技術(shù)掌控者的軟件架構(gòu)師，他需要對(duì)概要性架構(gòu)進(jìn)行細(xì)化。站在一個(gè)較高的地方，對(duì)整個(gè)系統(tǒng)不僅在業(yè)務(wù)邏輯上有清晰的理解和表述，而且要站在開(kāi)發(fā)、測(cè)試、部署等人員的角度上去進(jìn)行綜合設(shè)計(jì),很多時(shí)候團(tuán)隊(duì)部分成員在技能和專業(yè)知識(shí)上不是很成熟,在項(xiàng)目中,可以通過(guò)培訓(xùn)或者知識(shí)點(diǎn)的補(bǔ)充讓成員更快的融入項(xiàng)目中,并很好的領(lǐng)會(huì)架構(gòu),使架構(gòu)能真正的成為指導(dǎo),能用起來(lái)。讓項(xiàng)目組成員真正的以架構(gòu)為核心,不要走出這個(gè)圈圈。并且配合項(xiàng)目經(jīng)理做好對(duì)投資人、上級(jí)領(lǐng)導(dǎo)的溝通工作。在第5章的5視圖法這個(gè)工具在此處可以發(fā)揮較大的作用。架構(gòu)師給出的5視圖。對(duì)概要性架構(gòu)是一種補(bǔ)充和完善。
2. 本文也對(duì)分層架構(gòu)和各分層和模塊，在交互接口和交互機(jī)制提出了強(qiáng)調(diào)。不僅懂原理，而且要在實(shí)踐中用起來(lái)。我甚至覺(jué)得，在各角色人員的分工和合作方面。也可以更加緊密的和項(xiàng)目經(jīng)理合作，將各工種的合作方式、接口、機(jī)制進(jìn)行定義。以更有效的提高工作效率。減少溝通上的時(shí)間和資源損失。并且架構(gòu)師是站在整體的角度來(lái)考慮問(wèn)題，所以可以將共同的部分抽象出來(lái)，并建立一套調(diào)用機(jī)制。在細(xì)節(jié)上，可以和技術(shù)員們共同討論，以完善和優(yōu)化調(diào)用機(jī)制。
3. 在對(duì)一個(gè)系統(tǒng)的分析方法上，提出的按廣度和按深度的不同考慮角度是很有益的。其實(shí)，我個(gè)人感覺(jué)，在實(shí)際操作中，其實(shí)是在不斷的交互。不斷的螺旋上升的過(guò)程。結(jié)合5視圖法,只有這種,才能更加清晰,更加快速的將系統(tǒng)的藍(lán)圖展現(xiàn)在眾人面前。設(shè)計(jì)也是需要效率的。
4.團(tuán)隊(duì)開(kāi)發(fā)的方式和作用。文中不僅對(duì)大團(tuán)隊(duì)合作開(kāi)發(fā)的方式提出了有益的指導(dǎo)。而且我覺(jué)得稍加改變，也可以運(yùn)用到小團(tuán)隊(duì)、小項(xiàng)目的合作開(kāi)發(fā)中。比如和快速拋棄原型法結(jié)合。一二個(gè)開(kāi)發(fā)和美工就可以利用.net快速的開(kāi)發(fā)。如果在小團(tuán)隊(duì)中，有高明的架構(gòu)做為指導(dǎo)，再結(jié)合較成熟的企業(yè)框架的應(yīng)用。這幾桿槍也可以發(fā)揮出小炮的威力的。
5.在架構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)間的關(guān)系及應(yīng)用。結(jié)合需求分析的方法。可以指導(dǎo)開(kāi)發(fā)人員制作詳細(xì)設(shè)計(jì)。減少架構(gòu)師的工作量和培訓(xùn)提升開(kāi)發(fā)人員在設(shè)計(jì)方面的能力。
6.帶領(lǐng)團(tuán)隊(duì)一起進(jìn)步。一起把項(xiàng)目做細(xì)做好。怎么把團(tuán)隊(duì)成員的思想往一處帶是很重要的。團(tuán)隊(duì)中，有可能有初程、中程、高程。大家的經(jīng)歷、特長(zhǎng)也不盡相同。那么怎么培訓(xùn)就顯示尤為重要了。對(duì)一些基礎(chǔ)性的常識(shí)、或者專業(yè)的術(shù)語(yǔ)在團(tuán)隊(duì)內(nèi)進(jìn)行普及。不同的崗位在項(xiàng)目的不同階段，能給出指導(dǎo)性的綱領(lǐng)計(jì)劃、執(zhí)行方法、相關(guān)知識(shí)獲取、學(xué)習(xí)方法也可以使項(xiàng)目組成員更好的執(zhí)行架構(gòu)思想和團(tuán)結(jié)在架構(gòu)師周圍。更有利于架構(gòu)的推廣。當(dāng)然，能帶出架構(gòu)師的人。更是牛人。 | 
免費(fèi)注冊(cè)
發(fā)表于 2011-03-10 14:36
