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

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

　　同時一直不斷的請教自己的一些前輩，或者同事，不同人都不同的說法，有人說：搞架構(gòu)的，要懂很懂底層例如從匯編到C，要懂算法, 有人說：要懂很多語言，例如Java, C++,C#等，而且要懂很多的數(shù)據(jù)庫SQL SERVER, Oracle，還有人說：對技術(shù)很因為我都要很熟，還有人說：架構(gòu)師起碼要搞十幾年才行....最后給我的感覺就是：什么都要懂，要很精，那就是“簡直神”級別的人物：無所不知，無所不通。

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

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

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

　　青澀的歷程

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

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

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

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

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

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

　　之所以說這個過程是“青澀“，因為不成熟，常常是硬套，結(jié)果是使用起來不爽，而且問題多----為了使用而使用。這個過程就好比買衣服：在買衣服的時候，不是從個人的身型和喜好出發(fā)，而是先看衣服，然后用衣服來”套”人，難免讓人不舒服。

　　什么是設(shè)計

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

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

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

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

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

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

　　簡單的說，設(shè)計就是：，在頭腦中對于某個問題的清晰的實(shí)現(xiàn)過程。

　　走近設(shè)計

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

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

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

　　統(tǒng)一基本概念

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

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

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

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

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

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

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

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

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

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

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

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

　　今天就暫時寫到這里：下一篇進(jìn)入實(shí)戰(zhàn): 測試 & 設(shè)計

NET技術(shù)：走向ASP.NET架構(gòu)設(shè)計——第一章：走向設(shè)計，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。