開篇之前我想先說說當(dāng)年開發(fā)的那點(diǎn)事兒：大約10年前吧，我還是一個(gè)程序員的時(shí)候經(jīng)常都是遇到這樣的項(xiàng)目開發(fā)流程： 

• 解決方案 ：滿足客戶目的和投標(biāo)用的一堆文檔（不少還是互聯(lián)網(wǎng)上抄的） ，是以Word為主的純文字。
• 投標(biāo)完成和客戶付訂金后項(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)最足的成員參與編寫設(shè)計(jì)。倒霉的時(shí)候我們會得到一份按照軟件工程學(xué)的純中文形式的設(shè)計(jì)想法(抱歉我只能這樣來形容)，而更糟的情況是得到一份完全看不懂的Rose文檔（那個(gè)年代可是UML大放異彩的時(shí)代，而當(dāng)時(shí)我對UML完全就是個(gè)***）
• 開發(fā)：到這里才有我參與的份，前面的內(nèi)容通常作為項(xiàng)目組中低層的人員是不透明的。得到“設(shè)計(jì)”后，我們只能靠自己的“猜想”來實(shí)現(xiàn)，***拿著界面給經(jīng)理看是否符合他的“設(shè)計(jì)要求”。 
• 測試？ 這項(xiàng)目是沒有的，只要程序能跑通直接就交付了。

項(xiàng)目的結(jié)果不言而喻，最多的溝通就是吵架與被訓(xùn)斥還有就是被客戶抱怨。在這種例子很可笑，但更可笑的是至今我還聽到不少的朋友跟我說起這種類似的苦B經(jīng)歷。他們不是沒有設(shè)計(jì)，不是沒有溝通也不是沒有管理，只是每個(gè)人都在用自己方式在表達(dá)，沒有共同的語言和溝通方式。那么換個(gè)溝通能力很強(qiáng)大的項(xiàng)目經(jīng)理會改變這種境況嗎？ 可能可以，但遇到最多的只能是改善，只是苦B這個(gè)角色換成項(xiàng)目經(jīng)理而已，因?yàn)楸举|(zhì)上沒有多大的變化。

我很感恩能有這么讓人難受的開發(fā)經(jīng)歷，因?yàn)樘y過了所以才促成當(dāng)時(shí)的我去想辦法，去學(xué)習(xí)***努力去改變。接下來的部分會是我將這10多年來的經(jīng)歷進(jìn)行的一些總結(jié)，因?yàn)槲覍W(xué)的東東很雜當(dāng)時(shí)在大學(xué)里根本沒有這些知識只能靠在項(xiàng)目實(shí)踐中摸索前行，我受MSF與敏捷開發(fā)的影響很大，并且我是一個(gè)反UML人士，但我并沒有完全去采用某一種標(biāo)準(zhǔn)化的開發(fā)方法與開發(fā)流程，長年來只是以我對這些方法論的理解應(yīng)用到我的項(xiàng)目里，而在這里我不想過多地討論關(guān)于開發(fā)方法論與項(xiàng)目管理的內(nèi)容，而只是將其中與架構(gòu)和設(shè)計(jì)相關(guān)的內(nèi)容抽取出來論述。

表達(dá)思維

架構(gòu)師的職責(zé)

有效溝通

本文的主要內(nèi)容說得簡單一點(diǎn)就是架構(gòu)師銷售自己的設(shè)計(jì)的一些方式與方法。除了開發(fā)能力與設(shè)計(jì)能力以外“有效溝通”也是架構(gòu)師的很重要一項(xiàng)技能。架構(gòu)師與項(xiàng)目經(jīng)理不同主要工作時(shí)間與精力不是全放在溝通上，但如果溝通不當(dāng)就會出現(xiàn)因?yàn)榉磸?fù)溝通而大量消耗架構(gòu)師的設(shè)計(jì)時(shí)間，甚至設(shè)計(jì)出讓人難以理解的架構(gòu)，就算設(shè)計(jì)本身的含金量再高，在沒有找到伯樂之前也只能處于“曲高和寡”的尷尬局面。我之所以將溝通看作一項(xiàng)修煉的另一個(gè)原因是這些內(nèi)容都是從書看不到的，只能從實(shí)戰(zhàn)中摸趴滾打慢慢積累而成，不同的經(jīng)歷可能也會有不一樣的看法與心得，而接下來就是我積累多年的一點(diǎn)經(jīng)驗(yàn)的總結(jié)：

如果說開發(fā)流程是大的迭代那么設(shè)計(jì)就是經(jīng)歷一次次的小迭代以至于完善，項(xiàng)目的每個(gè)參與者的想法與建議都是架構(gòu)師修正設(shè)計(jì)，積累迭代的參考來源,。所以，架構(gòu)師的溝通是需要雙向激蕩的。

我按照項(xiàng)目中與架構(gòu)師溝通頻率***的角色、掌握的技能、信息的需求進(jìn)行了歸類，這樣將更便于了解怎么樣的溝通方式最為有效：

銷售  

• 溝通的需求：從設(shè)計(jì)中尋找賣點(diǎn)與特色，豐富銷售方案和定制預(yù)售計(jì)劃。
• 知識技能：對開發(fā)或深入的技術(shù)內(nèi)容可能只存在于概念性的理解、掌握市場的***手信息并且對客戶的需求最為了解。
• 推薦工具：特色列表 (Full Feature List)，字段：特色功能(Feature)+說明(Summary)

以產(chǎn)品開發(fā)（做項(xiàng)目會省事，沒有這一步）為例，我與銷售討論整個(gè)產(chǎn)品的***有特色的10項(xiàng)目功能（實(shí)際上3項(xiàng)就夠了，實(shí)踐告訴我只有前3項(xiàng)是別人記得最深刻的），這10項(xiàng)特色我們又稱之為“購買理由”，然后是整個(gè)系統(tǒng)全部特色功能（Full Features）。我經(jīng)常會與銷售因?yàn)槟硞€(gè)特色功能而經(jīng)常激烈地碰撞，但***銷售所提出的意見與建議往往發(fā)揮著最重要的作用，有時(shí)甚至直接影響到項(xiàng)目的可行性。 

修練的法門：

• 拋棄一切技術(shù)實(shí)現(xiàn)細(xì)節(jié)，寫/說出產(chǎn)品最重要的三個(gè)特色
• 拋棄一切技術(shù)實(shí)現(xiàn)細(xì)節(jié)，用心聆聽“非專業(yè)”的意見

項(xiàng)目經(jīng)理 

• 溝通需求：根據(jù)設(shè)計(jì)進(jìn)行時(shí)間估算、準(zhǔn)備項(xiàng)目資源與工作分解。
• 知識技能：大多是熟悉體系架構(gòu)類的知識（需要了解他/她是偏向于技術(shù)還是管理），熱衷于溝通與跟蹤
• 溝通工具：Excel
• 圖形工具：架構(gòu)圖、原理圖

項(xiàng)目經(jīng)理是架構(gòu)師在項(xiàng)目中最重要的伙伴，因?yàn)樗谪?fù)責(zé)跟蹤與保證你的設(shè)計(jì)被實(shí)現(xiàn)的全過程，是項(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)。

修煉法門：用最簡單的圖形視覺化設(shè)計(jì)

以下這兩個(gè)圖是我為數(shù)不多的公開項(xiàng)目中可以拿出來作為示例的，我用的設(shè)計(jì)工具是Excel：

圖例1：技術(shù)架構(gòu)

圖例2：應(yīng)用程序架構(gòu)

注：這兩個(gè)圖例是我的一個(gè)多年的開源項(xiàng)目DotNetAge CMS的架構(gòu)圖，有興趣的朋友可以訪問GitHub或者 DotNetAge (英文)官網(wǎng)了解其它的相關(guān)內(nèi)容 

開發(fā) 

• 溝通需求：根據(jù)設(shè)計(jì)要求進(jìn)行技術(shù)準(zhǔn)備、部署開發(fā)環(huán)境、編寫DEMO以及最終編碼，關(guān)心自己所負(fù)責(zé)的技術(shù)細(xì)節(jié)與實(shí)現(xiàn)方法。 
• 知識技能：掌握或精通特定的開發(fā)工具及開發(fā)技巧
• 溝通工具：范例代碼
• 圖形工具：序列圖，狀態(tài)圖，類圖

與開發(fā)人員溝通是最困難也是最有思想激蕩的環(huán)節(jié)，開發(fā)人員就像是小朋友一般富有嘗試新事物的膽氣與想法，在沒有制度與行政壓力的作用下要讓他們完完全全“遵守紀(jì)律”可不是一件容易的事。我并不認(rèn)為架構(gòu)師或者項(xiàng)目經(jīng)理在地位與行政上要領(lǐng)導(dǎo)其它的成員，這種“自然層級”并不利于溝通，反而容易讓項(xiàng)目組變成“一言堂”。我認(rèn)為與開發(fā)人員有效溝通的***方法就是“用代碼說話”，這也是為什么我在***篇文章就提出架構(gòu)師也需要是一個(gè)代碼控的另一原因。

我們交付到開發(fā)人員手上的都是空的公共接口或是公共類，開發(fā)人員是不能隨意改動任何接口、類、方法的命名的，這是一種最基本的約定，否則就亂套了。另外就是針對核心、多人使用、原理復(fù)雜的代碼必須帶有代碼范例。代碼范例就是與開發(fā)人員產(chǎn)生討論與激蕩的專用區(qū)域，也是為以后加入項(xiàng)目的人員提供的快速入門的***途徑，可以在很大的程度上降低不可見的、難實(shí)現(xiàn)、高風(fēng)險(xiǎn)代碼出現(xiàn)的機(jī)率。

修煉的法門：一邊設(shè)計(jì)一邊寫范例代碼，讓范例代碼成為設(shè)計(jì)的一部分

測試 

• 溝通需求：根據(jù)設(shè)計(jì)劃分測試粒度、測試的覆蓋范圍、準(zhǔn)備測試環(huán)境、定制測試計(jì)劃
• 知識技能：掌握各種測試方法、對Bug的所在有著天然的直覺。
• 溝通工具：類使用參考
• 圖形工具：架構(gòu)圖，序列圖，狀態(tài)圖，類圖

我認(rèn)為測試人員的架構(gòu)能力往往并不亞于任何的架構(gòu)師。能從常規(guī)化測試（單元測試、界面測試）發(fā)現(xiàn)問題是最為初等的測試人員；能從系統(tǒng)性能、流程或架構(gòu)中發(fā)現(xiàn)問題的測試靠的是經(jīng)驗(yàn)，閱歷甚至是一種直覺或者說是能“嗅”出問題的所在（在下一篇文章中我將會詳細(xì)解釋這種能力的源泉），這才是高級的測試人員。與測試人員的溝通與開發(fā)有點(diǎn)類似，只是當(dāng)沒有高級的測試人員配置時(shí)，架構(gòu)師也只能充當(dāng)這個(gè)角色，作為軟件的設(shè)計(jì)師是最能了解自己的系統(tǒng)可能存在的問題，在溝通時(shí)這些“問題”就是溝通的重點(diǎn)，必要時(shí)需要反復(fù)地觀察測試報(bào)告的結(jié)果，以找出“隱患”所在。在這里，所謂的修煉法門與上一點(diǎn)基本相同。

在此只對常見角色進(jìn)行大至的分類，按我們采用的開發(fā)方法不同可能還會存在更多的其它角色如：RM（發(fā)布經(jīng)理），TM（技術(shù)經(jīng)理）等等就不作一一細(xì)分了。

#p#

駕馭方法論

前文更多在探討如何向不同角色的人去表達(dá)自己的設(shè)計(jì)與思想的一些方法與見解，而作為架構(gòu)師自身的能力也由為重要。對方法論的掌握、理解與實(shí)踐就成為架構(gòu)師真正的“本錢”，用流行一點(diǎn)的語言就是所謂的“核心價(jià)值(Core Value)”。

我是一個(gè)很愚鈍的人，10多年來讀了很多的這方面的知識但真正能理解并用起來的也就兩三個(gè)，實(shí)在是由于環(huán)境、閱歷所限，很多理論沒有特定的環(huán)境也只能當(dāng)小說看。通過對各種方法論的學(xué)習(xí), 我悟到了一個(gè)心得：

“ 方法論的學(xué)習(xí)曲線是迭代的，也就是說同樣的理論在經(jīng)過不同的經(jīng)歷后再次重新學(xué)習(xí)就會有更深入的理解和新的領(lǐng)悟。”

 單單是《設(shè)計(jì)模式》一書我就從來沒有停止過迭代式的學(xué)習(xí)與實(shí)踐，而每一次實(shí)踐我都能得到一次新的領(lǐng)悟與體會。

 我會在下一篇文章中講述我認(rèn)為最有迭代學(xué)習(xí)價(jià)值的方法論。

 接下來就說說我認(rèn)為在設(shè)計(jì)中很用的一些方法論，以及我對這些方法論的一些總結(jié)。

框架理論

“框架”一詞近年來隨著 .net framework 的成功推廣感覺上都被用爛了，什么東東都會加上個(gè)XXX框架，可能是源于市場需求吧。我接觸“框架”這個(gè)詞或者說這個(gè)理論是在.net 誕生以前，在開始探討框架之前，我在 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í)際的程序，接口或開發(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ì)上，我對框架的理解是：框架是用于定義并鎖定對某個(gè)概念的理解范圍與實(shí)現(xiàn)的邊界，在既定的邊界下可具體化至其實(shí)現(xiàn)、并能迭代進(jìn)化的一份設(shè)計(jì)指引，是架構(gòu)師手上總的設(shè)計(jì)藍(lán)圖。這是我喜歡使用的一種方法論，微軟在MSF中的Function Spec (功能說明書)與之有點(diǎn)類似。它是一份對用戶需求以技術(shù)架構(gòu)形式***次細(xì)化的一種輸出。我喜歡這種方法論的原因是“簡單”，“靈活度高”，不需要標(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)，有共同的圖景自然就會產(chǎn)生共同的討論點(diǎn)，鎖定設(shè)計(jì)與話題的邊界。同時(shí)也是系統(tǒng)進(jìn)化的重要依據(jù)。

定義邊界 (Compressive Definitions)

所謂的邊界其實(shí)是對要畫出來的模塊的作用有一個(gè)明確并且清晰的文字表述，讓讀者能在建立全景藍(lán)圖后可以深入地了解每一個(gè)部分的具體含義，從而加深入系統(tǒng)的認(rèn)識。

怎樣學(xué)習(xí)

最簡單的入手辦法就是從你所熟習(xí)或者了解的系統(tǒng)入手，將其框架重新描繪出來。然后將你所了解的每個(gè)部分的定義套入其中，你將會發(fā)現(xiàn)你對現(xiàn)有的系統(tǒng)建立起一個(gè)全新的認(rèn)知。而關(guān)于工具的話可以用最原始的紙和筆，熟練后用Excel的夠了（想更為美觀可以用PhotoShop）, 最重要的一點(diǎn)是不要讓工具分散你思考的集中度，所以簡單就好。

至此，如果你開始嘗試這個(gè)方法可能你就會明白，為何我這個(gè)系列的開篇需要花那么長的篇幅去說明成為架構(gòu)師先得成為代碼控的必要性，因?yàn)?span style="background-color: rgb(255,255,0)">從藍(lán)圖開始既需要超越語言限制又需要對語言有深刻的了解。

UML

要成為架構(gòu)師的話，UML則是一門必修課。相關(guān)的資料與學(xué)習(xí)資源極其豐富，至于相關(guān)的學(xué)習(xí)方法也非常個(gè)性化，能掌握就好在此不作過多的贅述。在此，只是想分享一些我在學(xué)習(xí)和使用UML的一些心得。首先，在入手UML前必須非常熟悉對面向?qū)ο蟮乃谢靖拍罘駝t基本上是浪費(fèi)時(shí)間的。然后是有選擇性的學(xué)習(xí)，UML畢竟是一個(gè)非常陳舊的方法論即使到2.0版本如果真的全部安照UML的理論作為核心開發(fā)指導(dǎo)會非?？拥?，它是個(gè)重武器！看看當(dāng)年最牛X設(shè)計(jì)工具： Rational rose 雖然強(qiáng)大，但我覺得它更像個(gè)玩具。他的所謂文檔也只能是設(shè)計(jì)師級的人看的，由其是Use Case基本上是個(gè)集丑陋與非人類思想為一體的圖形，我基本上不用，因?yàn)樗谂c人溝通和整理自己思路上顯得極為不便，還不如用文字直接寫兩句話能說明問題(純屬個(gè)人的吐槽)。

UML是設(shè)計(jì)的常識或者說用于建立共同的設(shè)計(jì)語言，但不要以其為藍(lán)本，它在發(fā)現(xiàn)類，抽象出接口、梳理類或類與類之的關(guān)系和交互性時(shí)有重要的作用。我的方法是只學(xué)圖形不學(xué)過程，能讓人看得懂的才是設(shè)計(jì)，也不需要特意安裝什么UML的專用工具，優(yōu)秀的IDE一般都會帶有一些基本的UML圖形工具，比如：VisualStudio 。簡言之：UML只是共同語言，“活用就好”。

設(shè)計(jì)模式

設(shè)計(jì)模式是架構(gòu)師解決復(fù)雜問題的一把雙刃劍，用好了問題可能會被大大簡化甚至是巧妙地解決，但用得不好可能也會讓體系架構(gòu)出現(xiàn)不可控制的膨脹而變成一個(gè)糟糕的設(shè)計(jì)。面對設(shè)計(jì)模式理念我們需要以清晰的態(tài)度面對，當(dāng)我們理解或掌握某種模式時(shí)肯定也會有一種嘗試的沖動，但請不要將這種頭腦發(fā)熱式的行為應(yīng)用到設(shè)計(jì)中來，有沖動就去做一個(gè)實(shí)際的范例。在理論上掌握與實(shí)際理解畢竟會有一段距離，將這種淺層次的理解直接放到設(shè)計(jì)中，一旦運(yùn)用不當(dāng)就會控制不住類的規(guī)模而造成設(shè)計(jì)錯(cuò)誤。前面這些話不是讓大家不去用設(shè)計(jì)模式而是需要慎用、活用，吃透了再用，為了能掌握它們我也吃不了少的苦頭，在此總結(jié)出一些運(yùn)用的經(jīng)驗(yàn)，以供參考：

明確動機(jī)

不要為模式而模式。模式本身是針對解決某一問題域所提出的一個(gè)高度抽象的對象模型，每種模式都會有明確的使用動機(jī)的說明，這個(gè)動機(jī)與我們的實(shí)際的需求是否匹配是衡量其適用性的標(biāo)準(zhǔn)。

建立局部架構(gòu)

在使用模式前，建議獨(dú)立的創(chuàng)建一個(gè)工程。把模式以TDD的方式邊實(shí)現(xiàn)，邊測試。網(wǎng)上雖然存在很多的模式實(shí)現(xiàn)的“例式”，但很多都寫得糊里糊涂的，真正能用的并不多，值得推薦的只能數(shù)Enterprise Library 了，它以模式為其礎(chǔ)也加入了MS的實(shí)踐算是一個(gè)設(shè)計(jì)者入門的寶庫。雖然EL的代碼很多，不過運(yùn)用我在***篇所提到的看代碼的方法來學(xué)習(xí)也不會很吃力。在開發(fā)人員使用工程的公共接口和類以前，架師最應(yīng)該做的就是模型測試, 采用了設(shè)計(jì)模式的架構(gòu)最為有效的文檔是范例代碼，這樣可以避免去解釋內(nèi)部原理的時(shí)間，開發(fā)者就是使用者會用就好。另外，作為設(shè)計(jì)者本身，寫范例代碼可以驗(yàn)證設(shè)計(jì)的準(zhǔn)確性與正確性，而對于測試用例的編寫也一份重要參考指南。有了范例代碼我們就可以同時(shí)向兩種角色（開發(fā)、測試）交付實(shí)際的設(shè)計(jì)結(jié)果。

理解組合的效果

標(biāo)準(zhǔn)的23種模式并不單單是獨(dú)立的，模式與模式之間的互用往往會產(chǎn)生1+1>2的效果。但同時(shí)需要注意的一點(diǎn)是，增大使用效果的同時(shí)也會同樣的增加系統(tǒng)復(fù)雜度。

設(shè)計(jì)模式是架構(gòu)師伴侶，她是為解決問題簡化問題而生的。綜觀23種模式都是在不同的場景圍繞 耦合度、封裝性、易用性為核心論述，因此我檢驗(yàn)運(yùn)用模式效果的簡單標(biāo)準(zhǔn)是： 

• 耦合度是否被降低了？
• 實(shí)現(xiàn)細(xì)節(jié)是否已被接口隱藏了（封裝性）？
• 外部接口實(shí)現(xiàn)是否簡單？

測試驅(qū)動（TDD）

大家都知道測試的重要性，但運(yùn)用于實(shí)際的并且貫徹整個(gè)開發(fā)過程的并不多見?？赡苁?ldquo;測試”的可選擇性與“Quickly and Dirty” 的思想讓測試始終沒有被放到一個(gè)絕對重要的位置上去。說實(shí)在話我也是最近兩三年才完全地體驗(yàn)到TDD給我?guī)淼姆奖阈耘c認(rèn)識到其中的重要性。由其是設(shè)計(jì)規(guī)模龐大的項(xiàng)目時(shí)，架構(gòu)師再強(qiáng)也不可能考慮到全面的細(xì)節(jié)問題，由其是代碼實(shí)現(xiàn)。而MOQ這一類的工具類庫的出現(xiàn)也非常好的幫助我去模擬出類被實(shí)現(xiàn)后的效果，能直接測試出模型中可能存在的隱性或顯性而被忽視的問題。在團(tuán)隊(duì)配合開發(fā)的流程中測試的作用更是貫穿全局。好的測試流程可以在無溝通的情況下讓項(xiàng)目經(jīng)理了解每個(gè)CheckPoint的完成情；讓架構(gòu)師能模擬實(shí)現(xiàn)，測試類模型和編寫使用范式；讓開發(fā)人員可擁有最小化的代碼運(yùn)行入口；正如前文所提到的，一名高級的測試其設(shè)計(jì)能力可與架構(gòu)師并肩，他們能從表象中發(fā)現(xiàn)架構(gòu)中可能隱含的問題所在。那能不能反過來說一名架構(gòu)師也應(yīng)該具有高級測試的相應(yīng)能力？很明顯答案是肯定的。架構(gòu)師最起碼的需要掌握的是測試驅(qū)動的相關(guān)知識，最起碼了解如何寫單元測試、順序測試并能使用MOQ來模擬接口實(shí)現(xiàn)等的基本測試方法。

小結(jié)

這一篇文章我并沒有與上篇一樣給出一些具體的方法，因?yàn)楸疚挠懻摰母嗟氖俏覂H有的一點(diǎn)點(diǎn)經(jīng)驗(yàn)的總結(jié)，而更多的是來源于思維上的。我極力地想用有限的文字能力去表達(dá)這種意識和思維，最終卻仍然覺得有很多的內(nèi)容未必能盡說，或者你也可以嘗試通過實(shí)踐來去檢驗(yàn)我以上的理論。而在下篇中我將會更為深入地討論在設(shè)計(jì)中我認(rèn)為高層次的內(nèi)容：“變化”，我一直想多舉出一些實(shí)例而并不想寫得與到處可見的“干貨”般無味，***還是那句：敬請期待吧。