淺談?wù)暭軜?gòu)設(shè)計(jì)的重要作用
總的來(lái)說(shuō)，國(guó)內(nèi)的多數(shù)企業(yè)仍然是采用“瀑布模型”作為軟件開(kāi)發(fā)過(guò)程的主要模型。雖然在采用瀑布模型的同時(shí)可能會(huì)引入原型法以及諸如MSF等其它軟件開(kāi)發(fā)方法與過(guò)程，但隨著項(xiàng)目時(shí)間的推進(jìn)，這種“瀑布模型”會(huì)慢慢演化為“邊做邊改模型”。
從事過(guò)軟件項(xiàng)目開(kāi)發(fā)的專業(yè)人士都有這樣的困惑:為什么到了項(xiàng)目接近尾聲的時(shí)候，仍然還有那么多沒(méi)有解決的問(wèn)題？
理論上講，應(yīng)該是先分析，后設(shè)計(jì)，再編碼，那為什么項(xiàng)目在交貨以后，我們還在不斷的編寫設(shè)計(jì)文檔？為什么每次客戶需求發(fā)生變更，我們又要投入大量的資源來(lái)應(yīng)對(duì)不斷變化的客戶需求？為什么軟件開(kāi)發(fā)會(huì)碰到這么多困難，我們天天加班加點(diǎn)，不斷地去解決開(kāi)發(fā)中碰到的種種問(wèn)題，可是問(wèn)題越解決越多，得到的效果卻那么不盡人意？
項(xiàng)目出現(xiàn)這些問(wèn)題，原因很多，概括起來(lái)可以分為兩種:管理因素和技術(shù)因素。國(guó)內(nèi)普遍重視管理因素，而忽視技術(shù)因素，所以出現(xiàn)層出不窮的問(wèn)題也就無(wú)法避免。
軟件架構(gòu)設(shè)計(jì)屬于技術(shù)因素，它位于軟件開(kāi)發(fā)過(guò)程的前期階段，架構(gòu)設(shè)計(jì)的過(guò)程，是分析客戶需求、挖掘非功能性需求、并將客戶需求所定義的領(lǐng)域知識(shí)轉(zhuǎn)化為軟件系統(tǒng)模型的過(guò)程，由此可見(jiàn)，架構(gòu)設(shè)計(jì)所涵蓋的范圍非常廣泛。
目前,國(guó)內(nèi)對(duì)于軟件架構(gòu)的認(rèn)識(shí),還存在這樣或那樣的誤區(qū)。難道只有當(dāng)設(shè)計(jì)人員在為軟件項(xiàng)目配備了充足的資源，然而卻得不到預(yù)期的結(jié)果時(shí)，才會(huì)反思:是不是軟件開(kāi)發(fā)本身出現(xiàn)了問(wèn)題?
架構(gòu)設(shè)計(jì)源于客戶需求
在進(jìn)行需求分析的過(guò)程中，系統(tǒng)分析員將客戶需求轉(zhuǎn)化為計(jì)算機(jī)模型，然而在這個(gè)過(guò)程中，系統(tǒng)分析員本身的特性也就決定了這一角色很難把握住客戶的非功能性需求。
需求需要挖掘，尤其對(duì)于大型的軟件系統(tǒng)而言，光靠系統(tǒng)分析員這個(gè)單一的角色，很難完成需求分析與挖掘的艱巨任務(wù)。在需求分析的過(guò)程中，架構(gòu)設(shè)計(jì)師更為關(guān)注的是系統(tǒng)的非功能性需求，例如穩(wěn)定性、可擴(kuò)展性、可維護(hù)性、安全性、高效性等等，這些需求都是需要挖掘的。
如何挖掘？挖掘方式取決于核心需求。舉個(gè)很簡(jiǎn)單的例子，客戶需要實(shí)現(xiàn)兩個(gè)系統(tǒng)的數(shù)據(jù)傳輸，這是個(gè)核心功能性需求，而在這個(gè)需求的背后，還包括了“傳輸過(guò)程要求可靠”、“需要采用一種特定的數(shù)據(jù)格式進(jìn)行傳輸”、“由于數(shù)據(jù)包含一定的機(jī)密因素，因此需要加密，并需要選擇合適的加密算法”等等一系列的非功能性需求。
此時(shí)，架構(gòu)設(shè)計(jì)師不僅需要了解客戶本身的功能需求，還需要能夠發(fā)掘非功能需求。因此，優(yōu)秀的架構(gòu)設(shè)計(jì)師一定是一個(gè)經(jīng)驗(yàn)豐富的需求工程師，需求分析讓架構(gòu)設(shè)計(jì)師知道，我需要考慮哪些因素，而深厚的軟件技術(shù)功底讓架構(gòu)設(shè)計(jì)師知道，如何去考慮這些因素?？梢?jiàn)，架構(gòu)設(shè)計(jì)源于客戶需求。
架構(gòu)設(shè)計(jì)源于對(duì)知識(shí)的不斷積累
首先應(yīng)該認(rèn)識(shí)到，沒(méi)有對(duì)領(lǐng)域知識(shí)、軟件系統(tǒng)特性與軟件技術(shù)等的深刻理解，就無(wú)從談及架構(gòu)設(shè)計(jì)，而深厚的領(lǐng)域知識(shí)與技術(shù)經(jīng)驗(yàn)則是源于不斷的積累。
目前，市場(chǎng)上確實(shí)很多產(chǎn)品在架構(gòu)上已經(jīng)非常成熟和穩(wěn)定，但這些產(chǎn)品的成熟架構(gòu)也是通過(guò)長(zhǎng)期不斷的實(shí)踐與積累才逐步形成的。經(jīng)驗(yàn)豐富的架構(gòu)設(shè)計(jì)師可以在開(kāi)發(fā)產(chǎn)品的同時(shí)總結(jié)出一套架構(gòu)模式，這對(duì)維護(hù)產(chǎn)品的體系結(jié)構(gòu)，以及開(kāi)發(fā)同類產(chǎn)品都有深遠(yuǎn)的意義。
從另一個(gè)角度講，產(chǎn)品的架構(gòu)并非一成不變，隨著技術(shù)的不斷創(chuàng)新與發(fā)展，新技術(shù)一定會(huì)被應(yīng)用到現(xiàn)有的系統(tǒng)架構(gòu)中。此時(shí)，軟件架構(gòu)可能需要進(jìn)行調(diào)整，我們也不能再說(shuō)，我們沒(méi)有必要去關(guān)心這些產(chǎn)品架構(gòu)了。
架構(gòu)設(shè)計(jì)是一種取舍過(guò)程
實(shí)現(xiàn)某一非功能性需求，可以有很多種方法，但并不是每種方法都是最合適的，這在架構(gòu)設(shè)計(jì)的過(guò)程中需要做出取舍。例如，為了使得軟件系統(tǒng)具有易擴(kuò)展、易更改的能力，我們可以采用插件體系結(jié)構(gòu)或內(nèi)嵌腳本系統(tǒng)結(jié)構(gòu)，兩者都可以使得軟件系統(tǒng)具有方便擴(kuò)展的能力。
然而，如果客戶的業(yè)務(wù)流程會(huì)經(jīng)常變化，或者軟件系統(tǒng)產(chǎn)品會(huì)應(yīng)用到具有不同業(yè)務(wù)流程的多個(gè)客戶時(shí)，采用后者可能會(huì)更加符合軟件本身的特點(diǎn)。
當(dāng)今IT業(yè)技術(shù)層出不窮，在特定的應(yīng)用場(chǎng)景中，采用何種技術(shù)何種模式最合適，這就是架構(gòu)設(shè)計(jì)的取舍。JAVA和.NET孰好孰壞？討論這樣的問(wèn)題也不再有意義。軟件工程大師Martin Fowler曾經(jīng)說(shuō)過(guò):架構(gòu)師是對(duì)所有重要事情做出決定的人，這一決定也囊括了取舍。
架構(gòu)設(shè)計(jì)將服務(wù)于整個(gè)開(kāi)發(fā)過(guò)程
良好的架構(gòu)設(shè)計(jì)不僅使得軟件系統(tǒng)能夠滿足客戶需求，它更為軟件系統(tǒng)帶來(lái)了安全性、穩(wěn)定性、可擴(kuò)展性等屬性，而這些屬性在應(yīng)對(duì)客戶需求變更、提高軟件可測(cè)試性與可維護(hù)性、降低維護(hù)成本、提高開(kāi)發(fā)效率等各方面都起著非常重要的作用。
客戶所需要的是可以用于生產(chǎn)實(shí)踐的最終產(chǎn)品，他們自然不會(huì)去關(guān)心你的軟件系統(tǒng)采用何種設(shè)計(jì)和架構(gòu)，但作為軟件系統(tǒng)的分析者、設(shè)計(jì)者和開(kāi)發(fā)者，我們必須為軟件產(chǎn)品尋求一種合理的架構(gòu)設(shè)計(jì)，因?yàn)樗粌H能夠使系統(tǒng)滿足非功能性需求，而且能夠降低開(kāi)發(fā)成本和維護(hù)費(fèi)用。
總之，架構(gòu)設(shè)計(jì)是軟件開(kāi)發(fā)過(guò)程的重要組成部分，它不是單純的技術(shù)，也不具有一種特定的形式，更不是與客戶需求無(wú)關(guān)的。良好的軟件架構(gòu)能夠服務(wù)于整個(gè)開(kāi)發(fā)過(guò)程，有效地降低項(xiàng)目風(fēng)險(xiǎn)，確保項(xiàng)目能夠朝著健康的方向發(fā)展。因此，我們必須重視架構(gòu)設(shè)計(jì)在軟件開(kāi)發(fā)中的重要作用。
【編輯推薦】
