前言：很多做開發(fā)的人都在不斷的摸索著，積極的學(xué)習(xí)，試圖找出一條走向架構(gòu)設(shè)計(jì)的成功法則。每當(dāng)有人問起我們的職業(yè)，我們也常常在說(shuō):”軟件設(shè)計(jì)”。有時(shí)，我就在想:”設(shè)計(jì)”，這個(gè)已經(jīng)被我們嚼爛了的詞，到底有多少人真正懂”設(shè)計(jì)”的含義。

　　自動(dòng)進(jìn)入IT，走在開發(fā)這條路上，就一直在不斷的摸索，尋找，苦思：如何能夠才能成為架構(gòu)師。于是在網(wǎng)絡(luò)上不斷的收集和閱讀架構(gòu)設(shè)計(jì)方面的書籍和資料，到處在找一些架構(gòu)師的傳記，文章和甚至是采訪資料。

　　同時(shí)一直不斷的請(qǐng)教自己的一些前輩，或者同事，不同人都不同的說(shuō)法，有人說(shuō)：搞架構(gòu)的，要懂很懂底層例如從匯編到C，要懂算法, 有人說(shuō)：要懂很多語(yǔ)言，例如Java, C++,C#等，而且要懂很多的數(shù)據(jù)庫(kù)SQL SERVER, Oracle，還有人說(shuō)：對(duì)技術(shù)很因?yàn)槲叶家苁欤€有人說(shuō)：架構(gòu)師起碼要搞十幾年才行....最后給我的感覺就是：什么都要懂，要很精，那就是“簡(jiǎn)直神”級(jí)別的人物：無(wú)所不知，無(wú)所不通。

　　架構(gòu)設(shè)計(jì)，被成真正的有技術(shù)的勞動(dòng)，架構(gòu)師，也幾乎是神話般的職位，也是很多開發(fā)人員夢(mèng)寐以求的目標(biāo)。常常是談架構(gòu)就肅然起敬。每次只要看到比自己強(qiáng)的人，心里一陣欣喜：可以想他們學(xué)習(xí)，請(qǐng)教。 我想不僅僅是我，很多搞開發(fā)的朋友也正走在這條路上，也許這條路永遠(yuǎn)沒有盡頭。也許離“架構(gòu)師“所需的水平還相差N遠(yuǎn)，但是有些東西需要分享給大家，共勉，學(xué)習(xí)。

　　本系列文章是將會(huì)介紹在項(xiàng)目中如何使用設(shè)計(jì)模式，面向?qū)ο笤O(shè)計(jì)原則以及best practice. 我將會(huì)以開發(fā)ASP.NET項(xiàng)目為例子來(lái)講述，當(dāng)然，因?yàn)槟Ｊ降冗@些知識(shí)是語(yǔ)言無(wú)關(guān)性的，也就是說(shuō)，在這里講述的使用方法和經(jīng)驗(yàn)技巧在WinForm，WPF，Silverlight同樣適用。

　　經(jīng)過(guò)半年的打造，本系列文章幾十萬(wàn)文字的草稿已經(jīng)完成，現(xiàn)在處于后期的整理和審稿中，并且會(huì)定期發(fā)布，本系列的特點(diǎn)是：實(shí)戰(zhàn)的例子比較的多，每一個(gè)概念都有會(huì)展開的講述。幾乎每個(gè)概念都都有完整的代碼例子，而且系列的最后將帶領(lǐng)大家用這些知識(shí)開發(fā)一個(gè)比較真實(shí)的項(xiàng)目，希望大家多多的支持！

本篇的議題如下：

青澀的歷程

什么是設(shè)計(jì)

走近設(shè)計(jì)

統(tǒng)一基本概念

青澀的歷程

　　編程很多的時(shí)候都是Hello World開始的，然后開始學(xué)習(xí)一些Demo，慢慢的學(xué)習(xí)一些示例項(xiàng)目，然后就開始在自己的項(xiàng)目中進(jìn)行模仿。

　　記得當(dāng)時(shí)PetShop出來(lái)之后，被稱為了三層設(shè)計(jì)的典范，我看到很多的項(xiàng)目的結(jié)構(gòu)都是完完全全的把PetShop"山寨"了一遍：代碼的結(jié)構(gòu)，類庫(kù)的名字幾乎都是一樣。于是大家就在模仿中一步步的走了出來(lái)，在后頭看看，有的人已經(jīng)完全理解了PetShop的思想，懂得其"神"，也許還有的人還是停留在"形"。

　　后來(lái)設(shè)計(jì)模式被炒的火了起來(lái)，于是模式開始”橫行”，常常聽到有人聽說(shuō)“面向?qū)ο笤O(shè)計(jì)就是使用設(shè)計(jì)模式開發(fā)項(xiàng)目“。于是在項(xiàng)目中開始蹩腳的，刻意的使用設(shè)計(jì)模式。甚至拿著設(shè)計(jì)模式的書籍，對(duì)照自己的代碼一步步的改，最后把自己的代碼改為書上某個(gè)模式描述的結(jié)構(gòu)。開始刻意的使用時(shí)在所難免的，如果僅僅只是停在設(shè)計(jì)模式中描述的的代碼結(jié)構(gòu)，即”形“上，而不理解背后的”神“，那么我們就很那達(dá)到那種應(yīng)用自如，自然流露的地步。

　　我也看到也很多的項(xiàng)目采用TDD，TDD是的好東西。但是很多的項(xiàng)目中還是“望文生義“：測(cè)試驅(qū)動(dòng)開發(fā)---就是要寫測(cè)試。這個(gè)測(cè)試就用來(lái)測(cè)試功能代碼的。于是項(xiàng)目中的每個(gè)方法都有對(duì)應(yīng)的測(cè)試，很多人埋怨TDD就是體力活，而且使用了TDD，什么好的效果都沒有看到，只是不斷的無(wú)畏的拖延項(xiàng)目的時(shí)間，而且后來(lái)竟然還是先寫功能代碼，再補(bǔ)上測(cè)試代碼。理解還是停在了TDD的”形”上，沒有領(lǐng)會(huì)得其”神”。寫測(cè)試很容易，寫好的測(cè)試就不容易。會(huì)彈鋼琴和會(huì)演奏是兩碼的事。

　　DDD開始被被推崇，于是項(xiàng)目中到處出現(xiàn)和DDD有關(guān)的一些詞語(yǔ):Entity, Repository, Aggregate, Service等。原本大家很熟悉的一些名字，例如BLL, DAL被這些”新”的詞語(yǔ)沖亂了。而且常常在糾結(jié)：Customer是作為聚合，那么Order需要作為聚合嗎？等等。

　　而且在項(xiàng)目一些的類庫(kù)的名字就開始混亂：Present, BLL, Repository…等等，各種組合。這只是說(shuō)明：對(duì)DDD的理解還是停在”形”上。

　　之所以說(shuō)這個(gè)過(guò)程是“青澀“，因?yàn)椴怀墒欤３Ｊ怯蔡祝Y(jié)果是使用起來(lái)不爽，而且問題多----為了使用而使用。這個(gè)過(guò)程就好比買衣服：在買衣服的時(shí)候，不是從個(gè)人的身型和喜好出發(fā)，而是先看衣服，然后用衣服來(lái)”套”人，難免讓人不舒服。

　　什么是設(shè)計(jì)

　　前面閑話了N多，來(lái)看看什么是設(shè)計(jì)。有一點(diǎn)，我想有一點(diǎn)大家是認(rèn)同的：“設(shè)計(jì)”一定要把軟件正確的實(shí)現(xiàn)。可是編程的現(xiàn)狀不是這樣的，編程被認(rèn)為是沒有思想的體力活，因?yàn)榫幊讨袥]有加入思考。在建筑中，建筑工程師和民工的區(qū)別就在對(duì)建筑的“思考”上。

　　設(shè)計(jì)就是思考的過(guò)程。在這個(gè)過(guò)程中思考軟件如何做出來(lái)。大家很多都看過(guò)Wrox出版的系列書籍：Problem-Design-Solution。請(qǐng)問為什么會(huì)是：Problem-Design-Solution。

　　對(duì)于每一個(gè)要實(shí)現(xiàn)的功能，就是我們要解決的問題，即為Problem.

　　要解決這個(gè)問題，實(shí)現(xiàn)功能，我們要經(jīng)過(guò)思考，給出一些方案，這些方案往往不止一個(gè)，這個(gè)過(guò)程就是Design，尋求解決問題的方案。

　　經(jīng)過(guò)選擇，權(quán)衡，最后選取的Design就是成為這個(gè)問題的解決方案，即為Solution

　　其實(shí)任何功能的設(shè)計(jì)，基本上都是上面的三個(gè)步驟。其中在Design階段，所提出的方案一定是可以解決問題的，但是方案之間肯定各有利弊。而且在Design階段，基本上只要方案出來(lái)，實(shí)現(xiàn)的代碼骨架和流程在頭腦中起來(lái)有了70%-80%，也就是說(shuō)，一旦Design中的某一個(gè)方案被定為最終方案，要做的事情只是把頭腦中的想法”copy”到代碼中而已。這樣，起碼代碼是經(jīng)過(guò)深思熟慮出來(lái)的，出錯(cuò)率降低，項(xiàng)目的可控性就增加了。

　　簡(jiǎn)單的說(shuō)，設(shè)計(jì)就是：，在頭腦中對(duì)于某個(gè)問題的清晰的實(shí)現(xiàn)過(guò)程。

走近設(shè)計(jì)

　　整個(gè)的項(xiàng)目的開發(fā)過(guò)程就是對(duì)已一個(gè)個(gè)劃分的功能實(shí)現(xiàn)的過(guò)程，也是一次次重復(fù)Problem-Design-Solution的過(guò)程。在軟件開發(fā)中，有很多的開發(fā)模式，例如TDD,BDD,DDD等，還有一些不知名的，這些開發(fā)模式在Problem-Design-Solution的基礎(chǔ)上分別融入了自身的一些特性，例如DDD，就是把關(guān)注點(diǎn)放在建模上。但是不管采用那種開發(fā)的模式，思想還是一樣的：提出問題，分析問題，解決問題（Problem-Design-Solution）。

就像當(dāng)初我們?cè)趯W(xué)習(xí)計(jì)算機(jī)編程的時(shí)候，雖然有很多的編程語(yǔ)言可以實(shí)現(xiàn)編程，但是教材往往只選擇一種語(yǔ)言，例如Pascal，只要講明編程的思想就行了。下面就以TDD為例子，來(lái)講述如何設(shè)計(jì)。

本篇和下篇文章用TDD為例子，思想到了就可以了。相信很多朋友都看過(guò)"功夫熊貓”，熊貓的師傅從來(lái)沒有教給熊貓那一招"一陽(yáng)枯指"，但是熊貓最后自己卻會(huì)使用，后來(lái)其他弟子問師傅為什么，師傅說(shuō)“境界到了”

統(tǒng)一基本概念

　　馬上要以TDD為例子，盡管很多的文章已經(jīng)講述了TDD的一些理論和方法，個(gè)人認(rèn)為有必要在此之前，先統(tǒng)一 一些概念，以便加深TDD中的理解。而且我還會(huì)講述一些不一樣的東西。接下來(lái)的文章不會(huì)純粹的理論，都是實(shí)戰(zhàn)結(jié)合的，做到言之有物。

　　Test: 測(cè)試。一個(gè)測(cè)試就是用一個(gè)系統(tǒng)的方法或者步驟來(lái)確保程序的一個(gè)功能是正確的。

　　Pass: 我們說(shuō)某個(gè)功能Pass，就表明這個(gè)功能運(yùn)行正確。在TDD中，常常用綠色來(lái)表示Pass.

　　Fail: 說(shuō)明某個(gè)功能沒有按照我們預(yù)期的運(yùn)行。TDD中，常用紅色表示。

　　xUnit:其實(shí)xUnit就是指從sUnit演化而來(lái)的那些Test Framework的統(tǒng)稱，包含：nUnit（.NET中的一種測(cè)試框架）, jUnit（Java中的一種測(cè)試框架）,qUnit（.jQuery中的測(cè)試框架））等。

　　Test Fixture: 表示測(cè)試在被運(yùn)行之前必須進(jìn)入的一種狀態(tài)。 這種狀態(tài)就是代表在一個(gè)測(cè)試運(yùn)行之前有一些對(duì)象要被準(zhǔn)備。

　　Test Driven Development(TDD):是敏捷開發(fā)過(guò)程的一種，主要特定就是在寫功能代碼前先為它寫測(cè)試代碼。

　　Behavior Driven Development(BDD):建立在TDD的基礎(chǔ)之上，BDD的主要目的利用TDD在設(shè)計(jì)和編檔方面的優(yōu)勢(shì)來(lái)為用戶的業(yè)務(wù)增值。

　　Test Double: 當(dāng)我們?cè)谶M(jìn)行單元測(cè)試的時(shí)候，如果不能使用真實(shí)的組件的時(shí)候，我們用來(lái)替換真實(shí)組件的那個(gè)對(duì)象就稱為 test double。

　　Stub:很多書上把它翻譯為“樁”，其實(shí)它也是test double的一種，也是一種替換品，往往stub的對(duì)象不實(shí)現(xiàn)交互，只是作為一種輸入或者輸出來(lái)驗(yàn)證正確性。

　　Mock：可能大家對(duì)這個(gè)見的比較多，現(xiàn)在就有很多流行的mock框架。Mock，也是test double的一種，和stub意義很類似，但是mock往往被用來(lái)模仿行為比較復(fù)雜的對(duì)象。

　　Fake：它也是test double 的一種，與stub不同的是，fake的對(duì)象有實(shí)現(xiàn)了少量的交互功能，以便某個(gè)方法的測(cè)試更加容易。