走向.NET架構設計–第一章：走向設計

 

　　　　　　　　走向.NET架構設計--第一章：走向設計

　　前言：很多做開發的人都在不斷的摸索著，積極的學習，試圖找出一條走向架構設計的成功法則。每當有人問起我們的職業，我們也常常在說:”軟體設計”。有時，我就在想:”設計”，這個已經被我們嚼爛了的詞，到底有多少人真正懂”設計”的含義。

 

　　自動進入IT，走在開發這條路上，就一直在不斷的摸索，尋找，苦思：如何能夠才能成為架構師。於是在網路上不斷的收集和閱讀架構設計方面的書籍和資料，到處在找一些架構師的傳記，文章和甚至是採訪資料.....

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

 

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

 

　　本系列文章是將會介紹在項目中如何使用設計模式，物件導向設計原則以及best practice. 我將會以開發ASP.NET項目為例子來講述，當然，因為模式等這些知識是語言無關性的，也就是說，在這裡講述的使用方法和經驗技巧在WinForm，WPF，Silverlight同樣適用。

 

經過半年的打造，本系列文章幾十萬文字的草稿已經完成，現在處於後期的整理和審稿中，並且會定期發布，本系列的特點是：實戰的例子比較的多，每一個概念都有會展開的講述。幾乎每個概念都都有完整的代碼例子，而且系列的最後將帶領大家用這些知識開發一個比較真實的項目，希望大家多多的支援！

 

本篇的議題如下：

青澀的曆程

什麼是設計

走近設計

統一基本概念

 

　

 

　　青澀的曆程

　　編程很多的時候都是Hello World開始的，然後開始學習一些Demo，慢慢的學習一些樣本項目，然後就開始在自己的項目中進行模仿。

 

　　記得當時PetShop出來之後，被稱為了三層設計的典範，我看到很多的項目的結構都是完完全全的把PetShop"山寨"了一遍：代碼的結構，類庫的名字幾乎都是一樣。於是大家就在模仿中一步步的走了出來，在後頭看看，有的人已經完全理解了PetShop的思想，懂得其"神"，也許還有的人還是停留在"形"。

 

　　後來設計模式被炒的火了起來，於是模式開始”橫行”，常常聽到有人聽說“物件導向設計就是使用設計模式開發項目“。於是在項目中開始蹩腳的，刻意的使用設計模式。甚至拿著設計模式的書籍，對照自己的代碼一步步的改，最後把自己的代碼改為書上某個模式描述的結構。開始刻意的使用時在所難免的，如果僅僅只是停在設計模式中描述的的代碼結構，即”形“上，而不理解背後的”神“，那麼我們就很那達到那種應用自如，自然流露的地步。

 

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

 

　　DDD開始被被推崇，於是項目中到處出現和DDD有關的一些詞語:Entity, Repository, Aggregate, Service等。原本大家很熟悉的一些名字，例如BLL, DAL被這些”新”的詞語沖亂了。而且常常在糾結：Customer是作為彙總，那麼Order需要作為彙總嗎？等等。

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

 

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

 

　　什麼是設計

　　前面閑話了N多，來看看什麼是設計。有一點，我想有一點大家是認同的：“設計”一定要把軟體正確的實現。可是編程的現狀不是這樣的，編程被認為是沒有思想的體力活，因為編程中沒有加入思考。在建築中，建築工程師和民工的區別就在對建築的“思考”上。

 

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

 

　　對於每一個要實現的功能，就是我們要解決的問題，即為Problem.

　　要解決這個問題，實現功能，我們要經過思考，給出一些方案，這些方案往往不止一個，這個過程就是Design，尋求問題的解決方案。

　　經過選擇，權衡，最後選取的Design就是成為這個問題的解決方案，即為Solution

 

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

 

　　簡單的說，設計就是：，在頭腦中對於某個問題的清晰的實現過程。

 

　　走近設計

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

就像當初我們在學習電腦編程的時候，雖然有很多的程式設計語言可以實現編程，但是教材往往只選擇一種語言，例如Pascal，只要講明編程的思想就行了。下面就以TDD為例子，來講述如何設計。

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

 

　　統一基本概念

　　馬上要以TDD為例子，儘管很多的文章已經講述了TDD的一些理論和方法，個人認為有必要在此之前，先統一 一些概念，以便加深TDD中的理解。而且我還會講述一些不一樣的東西。接下來的文章不會純粹的理論，都是實戰結合的，做到言之有物。

 

　　Test: 測試。一個測試就是用一個系統的方法或者步驟來確保程式的一個功能是正確的。

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

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

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

　　Test Fixture: 表示測試在被運行之前必須進入的一種狀態。 這種狀態就是代表在一個測試回合之前有一些對象要被準備。

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

　　Behavior Driven Development(BDD):建立在TDD的基礎之上，BDD的主要目的利用TDD在設計和編檔方面的優勢來為使用者的業務增值。

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

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

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

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

 

　　今天就暫時寫到這裡：下一篇進入實戰: 測試 & 設計