建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
開(kāi)篇之前我想先說(shuō)說(shuō)當(dāng)年開(kāi)發(fā)的那點(diǎn)事兒：大約10年前吧，我還是一個(gè)程序員的時(shí)候經(jīng)常都是遇到這樣的項(xiàng)目開(kāi)發(fā)流程：
創(chuàng)新互聯(lián)是一家企業(yè)級(jí)云計(jì)算解決方案提供商,超15年IDC數(shù)據(jù)中心運(yùn)營(yíng)經(jīng)驗(yàn)。主營(yíng)GPU顯卡服務(wù)器，站群服務(wù)器，綿陽(yáng)服務(wù)器托管，海外高防服務(wù)器，機(jī)柜大帶寬、租用·托管，動(dòng)態(tài)撥號(hào)VPS，海外云手機(jī)，海外云服務(wù)器，海外服務(wù)器租用托管等。
- 解決方案 ：滿(mǎn)足客戶(hù)目的和投標(biāo)用的一堆文檔（不少還是互聯(lián)網(wǎng)上抄的） ，是以Word為主的純文字。
- 投標(biāo)完成和客戶(hù)付訂金后項(xiàng)目組成立，通常為（0至1）個(gè)項(xiàng)目經(jīng)理或者叫項(xiàng)目負(fù)責(zé)人+（1至N）個(gè)程序員 的項(xiàng)目組模式
- 設(shè)計(jì)：由項(xiàng)目的頭或者經(jīng)驗(yàn)最足的成員參與編寫(xiě)設(shè)計(jì)。倒霉的時(shí)候我們會(huì)得到一份按照軟件工程學(xué)的純中文形式的設(shè)計(jì)想法(抱歉我只能這樣來(lái)形容)，而更糟的情況是得到一份完全看不懂的Rose文檔（那個(gè)年代可是UML大放異彩的時(shí)代，而當(dāng)時(shí)我對(duì)UML完全就是個(gè)***）
- 開(kāi)發(fā)：到這里才有我參與的份，前面的內(nèi)容通常作為項(xiàng)目組中低層的人員是不透明的。得到“設(shè)計(jì)”后，我們只能靠自己的“猜想”來(lái)實(shí)現(xiàn)，***拿著界面給經(jīng)理看是否符合他的“設(shè)計(jì)要求”。
- 測(cè)試？ 這項(xiàng)目是沒(méi)有的，只要程序能跑通直接就交付了。
項(xiàng)目的結(jié)果不言而喻，最多的溝通就是吵架與被訓(xùn)斥還有就是被客戶(hù)抱怨。在這種例子很可笑，但更可笑的是至今我還聽(tīng)到不少的朋友跟我說(shuō)起這種類(lèi)似的苦B經(jīng)歷。他們不是沒(méi)有設(shè)計(jì)，不是沒(méi)有溝通也不是沒(méi)有管理，只是每個(gè)人都在用自己方式在表達(dá)，沒(méi)有共同的語(yǔ)言和溝通方式。那么換個(gè)溝通能力很強(qiáng)大的項(xiàng)目經(jīng)理會(huì)改變這種境況嗎？ 可能可以，但遇到最多的只能是改善，只是苦B這個(gè)角色換成項(xiàng)目經(jīng)理而已，因?yàn)楸举|(zhì)上沒(méi)有多大的變化。
我很感恩能有這么讓人難受的開(kāi)發(fā)經(jīng)歷，因?yàn)樘y過(guò)了所以才促成當(dāng)時(shí)的我去想辦法，去學(xué)習(xí)***努力去改變。接下來(lái)的部分會(huì)是我將這10多年來(lái)的經(jīng)歷進(jìn)行的一些總結(jié)，因?yàn)槲覍W(xué)的東東很雜當(dāng)時(shí)在大學(xué)里根本沒(méi)有這些知識(shí)只能靠在項(xiàng)目實(shí)踐中摸索前行，我受MSF與敏捷開(kāi)發(fā)的影響很大，并且我是一個(gè)反UML人士，但我并沒(méi)有完全去采用某一種標(biāo)準(zhǔn)化的開(kāi)發(fā)方法與開(kāi)發(fā)流程，長(zhǎng)年來(lái)只是以我對(duì)這些方法論的理解應(yīng)用到我的項(xiàng)目里，而在這里我不想過(guò)多地討論關(guān)于開(kāi)發(fā)方法論與項(xiàng)目管理的內(nèi)容，而只是將其中與架構(gòu)和設(shè)計(jì)相關(guān)的內(nèi)容抽取出來(lái)論述。
表達(dá)思維
架構(gòu)師的職責(zé)
世界上最難的兩件事是：將別人口袋的錢(qián)放到自己的口袋里面；將自己腦子的想法完整放到別人的腦子里面。在大家的印象中，項(xiàng)目經(jīng)理是項(xiàng)目中溝通得最多的角色，其實(shí)架構(gòu)師的溝通量也不遜于項(xiàng)目經(jīng)理。在國(guó)內(nèi)更多的情況是架構(gòu)師與項(xiàng)目經(jīng)理就是同一個(gè)人。作為系統(tǒng)/項(xiàng)目的總設(shè)計(jì)師，并不是單純只為客戶(hù)想出技術(shù)解決方案然后做出一份設(shè)計(jì)扔給項(xiàng)目組就完事了，而需要向每個(gè)位參與項(xiàng)目的成員或角色從不同的層面介紹或解釋設(shè)計(jì)原意與理念。
有效溝通
本文的主要內(nèi)容說(shuō)得簡(jiǎn)單一點(diǎn)就是架構(gòu)師銷(xiāo)售自己的設(shè)計(jì)的一些方式與方法。除了開(kāi)發(fā)能力與設(shè)計(jì)能力以外“有效溝通”也是架構(gòu)師的很重要一項(xiàng)技能。架構(gòu)師與項(xiàng)目經(jīng)理不同主要工作時(shí)間與精力不是全放在溝通上，但如果溝通不當(dāng)就會(huì)出現(xiàn)因?yàn)榉磸?fù)溝通而大量消耗架構(gòu)師的設(shè)計(jì)時(shí)間，甚至設(shè)計(jì)出讓人難以理解的架構(gòu)，就算設(shè)計(jì)本身的含金量再高，在沒(méi)有找到伯樂(lè)之前也只能處于“曲高和寡”的尷尬局面。我之所以將溝通看作一項(xiàng)修煉的另一個(gè)原因是這些內(nèi)容都是從書(shū)看不到的，只能從實(shí)戰(zhàn)中摸趴滾打慢慢積累而成，不同的經(jīng)歷可能也會(huì)有不一樣的看法與心得，而接下來(lái)就是我積累多年的一點(diǎn)經(jīng)驗(yàn)的總結(jié)：
如果說(shuō)開(kāi)發(fā)流程是大的迭代那么設(shè)計(jì)就是經(jīng)歷一次次的小迭代以至于完善，項(xiàng)目的每個(gè)參與者的想法與建議都是架構(gòu)師修正設(shè)計(jì)，積累迭代的參考來(lái)源,。所以，架構(gòu)師的溝通是需要雙向激蕩的。
我按照項(xiàng)目中與架構(gòu)師溝通頻率***的角色、掌握的技能、信息的需求進(jìn)行了歸類(lèi)，這樣將更便于了解怎么樣的溝通方式最為有效：
銷(xiāo)售
- 溝通的需求：從設(shè)計(jì)中尋找賣(mài)點(diǎn)與特色，豐富銷(xiāo)售方案和定制預(yù)售計(jì)劃。
- 知識(shí)技能：對(duì)開(kāi)發(fā)或深入的技術(shù)內(nèi)容可能只存在于概念性的理解、掌握市場(chǎng)的***手信息并且對(duì)客戶(hù)的需求最為了解。
- 推薦工具：特色列表 (Full Feature List)，字段：特色功能(Feature)+說(shuō)明(Summary)
以產(chǎn)品開(kāi)發(fā)（做項(xiàng)目會(huì)省事，沒(méi)有這一步）為例，我與銷(xiāo)售討論整個(gè)產(chǎn)品的***有特色的10項(xiàng)目功能（實(shí)際上3項(xiàng)就夠了，實(shí)踐告訴我只有前3項(xiàng)是別人記得最深刻的），這10項(xiàng)特色我們又稱(chēng)之為“購(gòu)買(mǎi)理由”，然后是整個(gè)系統(tǒng)全部特色功能（Full Features）。我經(jīng)常會(huì)與銷(xiāo)售因?yàn)槟硞€(gè)特色功能而經(jīng)常激烈地碰撞，但***銷(xiāo)售所提出的意見(jiàn)與建議往往發(fā)揮著最重要的作用，有時(shí)甚至直接影響到項(xiàng)目的可行性。
修練的法門(mén)：
- 拋棄一切技術(shù)實(shí)現(xiàn)細(xì)節(jié)，寫(xiě)/說(shuō)出產(chǎn)品最重要的三個(gè)特色
- 拋棄一切技術(shù)實(shí)現(xiàn)細(xì)節(jié)，用心聆聽(tīng)“非專(zhuān)業(yè)”的意見(jiàn)
這項(xiàng)修煉看起很簡(jiǎn)單，重于練心，做起來(lái)對(duì)于專(zhuān)業(yè)技術(shù)人員并不是容易的事，細(xì)節(jié)決定成敗，往往最簡(jiǎn)單最不引起注意的人或事可能是一個(gè)關(guān)鍵點(diǎn)。
項(xiàng)目經(jīng)理
- 溝通需求：根據(jù)設(shè)計(jì)進(jìn)行時(shí)間估算、準(zhǔn)備項(xiàng)目資源與工作分解。
- 知識(shí)技能：大多是熟悉體系架構(gòu)類(lèi)的知識(shí)（需要了解他/她是偏向于技術(shù)還是管理），熱衷于溝通與跟蹤
- 溝通工具：Excel
- 圖形工具：架構(gòu)圖、原理圖
項(xiàng)目經(jīng)理是架構(gòu)師在項(xiàng)目中最重要的伙伴，因?yàn)樗谪?fù)責(zé)跟蹤與保證你的設(shè)計(jì)被實(shí)現(xiàn)的全過(guò)程，是項(xiàng)目資源的提供者與進(jìn)度的控制者，他需要了解每一個(gè)檢查點(diǎn)(CheckPoint)與里程碑(Milestone)，這也是項(xiàng)目經(jīng)理與架構(gòu)師最重要的連接點(diǎn)（Connection Point）。我與項(xiàng)目經(jīng)理討論得最多的是系統(tǒng)實(shí)現(xiàn)的原理和實(shí)現(xiàn)各部分可能存在的難度和可能發(fā)生的風(fēng)險(xiǎn)。
修煉法門(mén)：用最簡(jiǎn)單的圖形視覺(jué)化設(shè)計(jì)
以下這兩個(gè)圖是我為數(shù)不多的公開(kāi)項(xiàng)目中可以拿出來(lái)作為示例的，我用的設(shè)計(jì)工具是Excel：
圖例1：技術(shù)架構(gòu)
圖例2：應(yīng)用程序架構(gòu)
注：這兩個(gè)圖例是我的一個(gè)多年的開(kāi)源項(xiàng)目DotNetAge CMS的架構(gòu)圖，有興趣的朋友可以訪問(wèn)GitHub或者 DotNetAge (英文)官網(wǎng)了解其它的相關(guān)內(nèi)容
開(kāi)發(fā)
- 溝通需求：根據(jù)設(shè)計(jì)要求進(jìn)行技術(shù)準(zhǔn)備、部署開(kāi)發(fā)環(huán)境、編寫(xiě)DEMO以及最終編碼，關(guān)心自己所負(fù)責(zé)的技術(shù)細(xì)節(jié)與實(shí)現(xiàn)方法。
- 知識(shí)技能：掌握或精通特定的開(kāi)發(fā)工具及開(kāi)發(fā)技巧
- 溝通工具：范例代碼
- 圖形工具：序列圖，狀態(tài)圖，類(lèi)圖
與開(kāi)發(fā)人員溝通是最困難也是最有思想激蕩的環(huán)節(jié)，開(kāi)發(fā)人員就像是小朋友一般富有嘗試新事物的膽氣與想法，在沒(méi)有制度與行政壓力的作用下要讓他們完完全全“遵守紀(jì)律”可不是一件容易的事。我并不認(rèn)為架構(gòu)師或者項(xiàng)目經(jīng)理在地位與行政上要領(lǐng)導(dǎo)其它的成員，這種“自然層級(jí)”并不利于溝通，反而容易讓項(xiàng)目組變成“一言堂”。我認(rèn)為與開(kāi)發(fā)人員有效溝通的***方法就是“用代碼說(shuō)話”，這也是為什么我在***篇文章就提出架構(gòu)師也需要是一個(gè)代碼控的另一原因。
我們交付到開(kāi)發(fā)人員手上的都是空的公共接口或是公共類(lèi)，開(kāi)發(fā)人員是不能隨意改動(dòng)任何接口、類(lèi)、方法的命名的，這是一種最基本的約定，否則就亂套了。另外就是針對(duì)核心、多人使用、原理復(fù)雜的代碼必須帶有代碼范例。代碼范例就是與開(kāi)發(fā)人員產(chǎn)生討論與激蕩的專(zhuān)用區(qū)域，也是為以后加入項(xiàng)目的人員提供的快速入門(mén)的***途徑，可以在很大的程度上降低不可見(jiàn)的、難實(shí)現(xiàn)、高風(fēng)險(xiǎn)代碼出現(xiàn)的機(jī)率。
修煉的法門(mén)：一邊設(shè)計(jì)一邊寫(xiě)范例代碼，讓范例代碼成為設(shè)計(jì)的一部分
測(cè)試
- 溝通需求：根據(jù)設(shè)計(jì)劃分測(cè)試粒度、測(cè)試的覆蓋范圍、準(zhǔn)備測(cè)試環(huán)境、定制測(cè)試計(jì)劃
- 知識(shí)技能：掌握各種測(cè)試方法、對(duì)Bug的所在有著天然的直覺(jué)。
- 溝通工具：類(lèi)使用參考
- 圖形工具：架構(gòu)圖，序列圖，狀態(tài)圖，類(lèi)圖
我認(rèn)為測(cè)試人員的架構(gòu)能力往往并不亞于任何的架構(gòu)師。能從常規(guī)化測(cè)試（單元測(cè)試、界面測(cè)試）發(fā)現(xiàn)問(wèn)題是最為初等的測(cè)試人員；能從系統(tǒng)性能、流程或架構(gòu)中發(fā)現(xiàn)問(wèn)題的測(cè)試靠的是經(jīng)驗(yàn)，閱歷甚至是一種直覺(jué)或者說(shuō)是能“嗅”出問(wèn)題的所在（在下一篇文章中我將會(huì)詳細(xì)解釋這種能力的源泉），這才是高級(jí)的測(cè)試人員。與測(cè)試人員的溝通與開(kāi)發(fā)有點(diǎn)類(lèi)似，只是當(dāng)沒(méi)有高級(jí)的測(cè)試人員配置時(shí)，架構(gòu)師也只能充當(dāng)這個(gè)角色，作為軟件的設(shè)計(jì)師是最能了解自己的系統(tǒng)可能存在的問(wèn)題，在溝通時(shí)這些“問(wèn)題”就是溝通的重點(diǎn)，必要時(shí)需要反復(fù)地觀察測(cè)試報(bào)告的結(jié)果，以找出“隱患”所在。在這里，所謂的修煉法門(mén)與上一點(diǎn)基本相同。
在此只對(duì)常見(jiàn)角色進(jìn)行大至的分類(lèi)，按我們采用的開(kāi)發(fā)方法不同可能還會(huì)存在更多的其它角色如：RM（發(fā)布經(jīng)理），TM（技術(shù)經(jīng)理）等等就不作一一細(xì)分了。
#p#
駕馭方法論
前文更多在探討如何向不同角色的人去表達(dá)自己的設(shè)計(jì)與思想的一些方法與見(jiàn)解，而作為架構(gòu)師自身的能力也由為重要。對(duì)方法論的掌握、理解與實(shí)踐就成為架構(gòu)師真正的“本錢(qián)”，用流行一點(diǎn)的語(yǔ)言就是所謂的“核心價(jià)值(Core Value)”。
我是一個(gè)很愚鈍的人，10多年來(lái)讀了很多的這方面的知識(shí)但真正能理解并用起來(lái)的也就兩三個(gè)，實(shí)在是由于環(huán)境、閱歷所限，很多理論沒(méi)有特定的環(huán)境也只能當(dāng)小說(shuō)看。通過(guò)對(duì)各種方法論的學(xué)習(xí), 我悟到了一個(gè)心得：
“ 方法論的學(xué)習(xí)曲線是迭代的，也就是說(shuō)同樣的理論在經(jīng)過(guò)不同的經(jīng)歷后再次重新學(xué)習(xí)就會(huì)有更深入的理解和新的領(lǐng)悟?！?/p>
單單是《設(shè)計(jì)模式》一書(shū)我就從來(lái)沒(méi)有停止過(guò)迭代式的學(xué)習(xí)與實(shí)踐，而每一次實(shí)踐我都能得到一次新的領(lǐng)悟與體會(huì)。
我會(huì)在下一篇文章中講述我認(rèn)為最有迭代學(xué)習(xí)價(jià)值的方法論。
接下來(lái)就說(shuō)說(shuō)我認(rèn)為在設(shè)計(jì)中很用的一些方法論，以及我對(duì)這些方法論的一些總結(jié)。
框架理論
“框架”一詞近年來(lái)隨著 .net framework 的成功推廣感覺(jué)上都被用爛了，什么東東都會(huì)加上個(gè)XXX框架，可能是源于市場(chǎng)需求吧。我接觸“框架”這個(gè)詞或者說(shuō)這個(gè)理論是在.net 誕生以前，在開(kāi)始探討框架之前，我在 WhatIs 上找到了一段在軟件框架方面比較貼切定義：
原文：
In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.
In computer systems, a framework is often a layered structure indicating what kind of programs can or should be built and how they would interrelate. Some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication should be standardized at some level of a network; and so forth. A framework is generally more comprehensive than a protocol and more prescriptive than a structure .
From Whatis.techtarget.com
譯文 【Ray】 通常地一個(gè)框架是為了解釋如何構(gòu)建某項(xiàng)有用的事物及其結(jié)構(gòu)的實(shí)現(xiàn)或概念的一份支持或指南。在計(jì)算機(jī)系統(tǒng)內(nèi)，框架通常被用于描述一個(gè)程序應(yīng)該構(gòu)建的層次結(jié)構(gòu)。某些系統(tǒng)架構(gòu)甚至?xí)瑢?shí)際的程序，接口或開(kāi)發(fā)工具集。一個(gè)框架指的可能是一套相關(guān)的函數(shù)集合、操作系統(tǒng)內(nèi)的某些層次、或者某個(gè)子系統(tǒng)內(nèi)的層次又或者是網(wǎng)絡(luò)中某個(gè)層次結(jié)構(gòu)下的標(biāo)準(zhǔn)化通信方式等等。
一個(gè)框架通常比一個(gè)協(xié)議的定義更為全面，比結(jié)構(gòu)的定義更為規(guī)范。
在設(shè)計(jì)上，我對(duì)框架的理解是：框架是用于定義并鎖定對(duì)某個(gè)概念的理解范圍與實(shí)現(xiàn)的邊界，在既定的邊界下可具體化至其實(shí)現(xiàn)、并能迭代進(jìn)化的一份設(shè)計(jì)指引，是架構(gòu)師手上總的設(shè)計(jì)藍(lán)圖。這是我喜歡使用的一種方法論，微軟在MSF中的Function Spec (功能說(shuō)明書(shū))與之有點(diǎn)類(lèi)似。它是一份對(duì)用戶(hù)需求以技術(shù)架構(gòu)形式***次細(xì)化的一種輸出。我喜歡這種方法論的原因是“簡(jiǎn)單”，“靈活度高”，不需要標(biāo)準(zhǔn)化（標(biāo)準(zhǔn)化的東西是不需要設(shè)計(jì)的只需要套用，那是模式），只需要掌握兩種原則就行了。
建立藍(lán)圖（Build A Whole Picture）
在閱讀框架文檔時(shí)只即使所有內(nèi)容都忘記了，只要整個(gè)設(shè)計(jì)圖景能印在讀者的腦海就達(dá)到目的了。這是一份指引，是思維的起點(diǎn)，有共同的圖景自然就會(huì)產(chǎn)生共同的討論點(diǎn)，鎖定設(shè)計(jì)與話題的邊界。同時(shí)也是系統(tǒng)進(jìn)化的重要依據(jù)。
定義邊界 (Compressive Definitions)
所謂的邊界其實(shí)是對(duì)要畫(huà)出來(lái)的模塊的作用有一個(gè)明確并且清晰的文字表述，讓讀者能在建立全景藍(lán)圖后可以深入地了解每一個(gè)部分的具體含義，從而加深入系統(tǒng)的認(rèn)識(shí)。
怎樣學(xué)習(xí)
最簡(jiǎn)單的入手辦法就是從你所熟習(xí)或者了解的系統(tǒng)入手，將其框架重新描繪出來(lái)。然后將你所了解的每個(gè)部分的定義套入其中，你將會(huì)發(fā)現(xiàn)你對(duì)現(xiàn)有的系統(tǒng)建立起一個(gè)全新的認(rèn)知。而關(guān)于工具的話可以用最原始的紙和筆，熟練后用Excel的夠了（想更為美觀可以用PhotoShop）, 最重要的一點(diǎn)是不要讓工具分散你思考的集中度，所以簡(jiǎn)單就好。
至此，如果你開(kāi)始嘗試這個(gè)方法可能你就會(huì)明白，為何我這個(gè)系列的開(kāi)篇需要花那么長(zhǎng)的篇幅去說(shuō)明成為架構(gòu)師先得成為代碼控的必要性，因?yàn)閺乃{(lán)圖開(kāi)始既需要超越語(yǔ)言限制又需要對(duì)語(yǔ)言有深刻的了解。
UML
要成為架構(gòu)師的話，UML則是一門(mén)必修課。相關(guān)的資料與學(xué)習(xí)資源極其豐富，至于相關(guān)的學(xué)習(xí)方法也非常個(gè)性化，能掌握就好在此不作過(guò)多的贅述。在此，只是想分享一些我在學(xué)習(xí)和使用UML的一些心得。首先，在入手UML前必須非常熟悉對(duì)面向?qū)ο蟮乃谢靖拍罘駝t基本上是浪費(fèi)時(shí)間的。然后是有選擇性的學(xué)習(xí)，UML畢竟是一個(gè)非常陳舊的方法論即使到2.0版本如果真的全部安照UML的理論作為核心開(kāi)發(fā)指導(dǎo)會(huì)非?？拥?，它是個(gè)重武器！看看當(dāng)年最牛X設(shè)計(jì)工具： Rational rose 雖然強(qiáng)大，但我覺(jué)得它更像個(gè)玩具。他的所謂文檔也只能是設(shè)計(jì)師級(jí)的人看的，由其是Use Case基本上是個(gè)集丑陋與非人類(lèi)思想為一體的圖形，我基本上不用，因?yàn)樗谂c人溝通和整理自己思路上顯得極為不便，還不如用文字直接寫(xiě)兩句話能說(shuō)明問(wèn)題(純屬個(gè)人的吐槽)。
UML是設(shè)計(jì)的常識(shí)或者說(shuō)用于建立共同的設(shè)計(jì)語(yǔ)言，但不要以其為藍(lán)本，它在發(fā)現(xiàn)類(lèi)，抽象出接口、梳理類(lèi)或類(lèi)與類(lèi)之的關(guān)系和交互性時(shí)有重要的作用。我的方法是只學(xué)圖形不學(xué)過(guò)程，能讓人看得懂的才是設(shè)計(jì)，也不需要特意安裝什么UML的專(zhuān)用工具，優(yōu)秀的IDE一般都會(huì)帶有一些基本的UML圖形工具，比如：VisualStudio 。簡(jiǎn)言之：UML只是共同語(yǔ)言，“活用就好”。
設(shè)計(jì)模式
設(shè)計(jì)模式是架構(gòu)師解決復(fù)雜問(wèn)題的一把雙刃劍，用好了問(wèn)題可能會(huì)被大大簡(jiǎn)化甚至是巧妙地解決，但用得不好可能也會(huì)讓體系架構(gòu)出現(xiàn)不可控制的膨脹而變成一個(gè)糟糕的設(shè)計(jì)。面對(duì)設(shè)計(jì)模式理念我們需要以清晰的態(tài)度面對(duì)，當(dāng)我們理解或掌握某種模式時(shí)肯定也會(huì)有一種嘗試的沖動(dòng)，但請(qǐng)不要將這種頭腦發(fā)熱式的行為應(yīng)用到設(shè)計(jì)中來(lái)，有沖動(dòng)就去做一個(gè)實(shí)際的范例。在理論上掌握與實(shí)際理解畢竟會(huì)有一段距離，將這種淺層次的理解直接放到設(shè)計(jì)中，一旦運(yùn)用不當(dāng)就會(huì)控制不住類(lèi)的規(guī)模而造成設(shè)計(jì)錯(cuò)誤。前面這些話不是讓大家不去用設(shè)計(jì)模式而是需要慎用、活用，吃透了再用，為了能掌握它們我也吃不了少的苦頭，在此總結(jié)出一些運(yùn)用的經(jīng)驗(yàn)，以供參考：
明確動(dòng)機(jī)
不要為模式而模式。模式本身是針對(duì)解決某一問(wèn)題域所提出的一個(gè)高度抽象的對(duì)象模型，每種模式都會(huì)有明確的使用動(dòng)機(jī)的說(shuō)明，這個(gè)動(dòng)機(jī)與我們的實(shí)際的需求是否匹配是衡量其適用性的標(biāo)準(zhǔn)。
建立局部架構(gòu)
在使用模式前，建議獨(dú)立的創(chuàng)建一個(gè)工程。把模式以TDD的方式邊實(shí)現(xiàn)，邊測(cè)試。網(wǎng)上雖然存在很多的模式實(shí)現(xiàn)的“例式”，但很多都寫(xiě)得糊里糊涂的，真正能用的并不多，值得推薦的只能數(shù)Enterprise Library 了，它以模式為其礎(chǔ)也加入了MS的實(shí)踐算是一個(gè)設(shè)計(jì)者入門(mén)的寶庫(kù)。雖然EL的代碼很多，不過(guò)運(yùn)用我在***篇所提到的看代碼的方法來(lái)學(xué)習(xí)也不會(huì)很吃力。在開(kāi)發(fā)人員使用工程的公共接口和類(lèi)以前，架師最應(yīng)該做的就是模型測(cè)試, 采用了設(shè)計(jì)模式的架構(gòu)最為有效的文檔是范例代碼，這樣可以避免去解釋內(nèi)部原理的時(shí)間，開(kāi)發(fā)者就是使用者會(huì)用就好。另外，作為設(shè)計(jì)者本身，寫(xiě)范例代碼可以驗(yàn)證設(shè)計(jì)的準(zhǔn)確性與正確性，而對(duì)于測(cè)試用例的編寫(xiě)也一份重要參考指南。有了范例代碼我們就可以同時(shí)向兩種角色（開(kāi)發(fā)、測(cè)試）交付實(shí)際的設(shè)計(jì)結(jié)果。
理解組合的效果
標(biāo)準(zhǔn)的23種模式并不單單是獨(dú)立的，模式與模式之間的互用往往會(huì)產(chǎn)生1+1>2的效果。但同時(shí)需要注意的一點(diǎn)是，增大使用效果的同時(shí)也會(huì)同樣的增加系統(tǒng)復(fù)雜度。
設(shè)計(jì)模式是架構(gòu)師伴侶，她是為解決問(wèn)題簡(jiǎn)化問(wèn)題而生的。綜觀23種模式都是在不同的場(chǎng)景圍繞 耦合度、封裝性、易用性為核心論述，因此我檢驗(yàn)運(yùn)用模式效果的簡(jiǎn)單標(biāo)準(zhǔn)是：
- 耦合度是否被降低了？
- 實(shí)現(xiàn)細(xì)節(jié)是否已被接口隱藏了（封裝性）？
- 外部接口實(shí)現(xiàn)是否簡(jiǎn)單？
設(shè)計(jì)模式濃縮了設(shè)計(jì)大師前輩們的思想與經(jīng)驗(yàn)精華，不是一本能速成的設(shè)計(jì)手冊(cè)。我們需要模式是因?yàn)槲覀冞€沒(méi)有總結(jié)出自己的***設(shè)計(jì)實(shí)踐，這需要我們長(zhǎng)期的實(shí)戰(zhàn)經(jīng)驗(yàn)積累。有了設(shè)計(jì)模式可以讓我們讓在大師的肩膀上去設(shè)計(jì)和創(chuàng)造。將設(shè)計(jì)模式反復(fù)學(xué)習(xí)，學(xué)懂、學(xué)通、活用直至我們忘掉模式，一切自然而成那才是屬于架構(gòu)師自己的設(shè)計(jì)領(lǐng)域與空間。
測(cè)試驅(qū)動(dòng)（TDD）
大家都知道測(cè)試的重要性，但運(yùn)用于實(shí)際的并且貫徹整個(gè)開(kāi)發(fā)過(guò)程的并不多見(jiàn)?？赡苁恰皽y(cè)試”的可選擇性與“Quickly and Dirty” 的思想讓測(cè)試始終沒(méi)有被放到一個(gè)絕對(duì)重要的位置上去。說(shuō)實(shí)在話我也是最近兩三年才完全地體驗(yàn)到TDD給我?guī)?lái)的方便性與認(rèn)識(shí)到其中的重要性。由其是設(shè)計(jì)規(guī)模龐大的項(xiàng)目時(shí)，架構(gòu)師再?gòu)?qiáng)也不可能考慮到全面的細(xì)節(jié)問(wèn)題，由其是代碼實(shí)現(xiàn)。而MOQ這一類(lèi)的工具類(lèi)庫(kù)的出現(xiàn)也非常好的幫助我去模擬出類(lèi)被實(shí)現(xiàn)后的效果，能直接測(cè)試出模型中可能存在的隱性或顯性而被忽視的問(wèn)題。在團(tuán)隊(duì)配合開(kāi)發(fā)的流程中測(cè)試的作用更是貫穿全局。好的測(cè)試流程可以在無(wú)溝通的情況下讓項(xiàng)目經(jīng)理了解每個(gè)CheckPoint的完成情；讓架構(gòu)師能模擬實(shí)現(xiàn)，測(cè)試類(lèi)模型和編寫(xiě)使用范式；讓開(kāi)發(fā)人員可擁有最小化的代碼運(yùn)行入口；正如前文所提到的，一名高級(jí)的測(cè)試其設(shè)計(jì)能力可與架構(gòu)師并肩，他們能從表象中發(fā)現(xiàn)架構(gòu)中可能隱含的問(wèn)題所在。那能不能反過(guò)來(lái)說(shuō)一名架構(gòu)師也應(yīng)該具有高級(jí)測(cè)試的相應(yīng)能力？很明顯答案是肯定的。架構(gòu)師最起碼的需要掌握的是測(cè)試驅(qū)動(dòng)的相關(guān)知識(shí)，最起碼了解如何寫(xiě)單元測(cè)試、順序測(cè)試并能使用MOQ來(lái)模擬接口實(shí)現(xiàn)等的基本測(cè)試方法。
小結(jié)
這一篇文章我并沒(méi)有與上篇一樣給出一些具體的方法，因?yàn)楸疚挠懻摰母嗟氖俏覂H有的一點(diǎn)點(diǎn)經(jīng)驗(yàn)的總結(jié)，而更多的是來(lái)源于思維上的。我極力地想用有限的文字能力去表達(dá)這種意識(shí)和思維，最終卻仍然覺(jué)得有很多的內(nèi)容未必能盡說(shuō)，或者你也可以嘗試通過(guò)實(shí)踐來(lái)去檢驗(yàn)我以上的理論。而在下篇中我將會(huì)更為深入地討論在設(shè)計(jì)中我認(rèn)為高層次的內(nèi)容：“變化”，我一直想多舉出一些實(shí)例而并不想寫(xiě)得與到處可見(jiàn)的“干貨”般無(wú)味，***還是那句：敬請(qǐng)期待吧。
新聞名稱(chēng)：架構(gòu)師修煉II-表達(dá)思維與駕馭方法論
網(wǎng)站網(wǎng)址：http://m.fisionsoft.com.cn/article/dhsoieo.html
