本篇寫于讀<Code Complete>之后，面對實際設(shè)計中的問題時產(chǎn)生的一些感悟，在這里和大家一起分享。。

第一頁

設(shè)計是個“鬼”命題。為什么呢？它又鬼在哪呢？

A wicked problem as one that could be clearly defined only by solving it or by solving part of it.

---Horst Rittel and Melvin Webber

這里是大師的定義。只有你解決了或者部分解決這個問題的時候，你才能清楚的定義它。

用白話講，只有你做了，你才知道它是怎么回事，怎么才能做好這件事。

所以，我常常拿到一個開發(fā)功能而又無從下手時，除了尋找支援，詢問別人，唯一剩下的路就是嘗試著去做。雖然是膽顫心驚、如履薄冰，但是做著做著就明白了。

我想，大師告訴我們這是一個鬼命題，第一,是告訴我們第一次摸著石頭過河是人類的認(rèn)知規(guī)律,開始時做錯了是正常的;第二,就是讓我們勇敢的去嘗試。

第二頁

設(shè)計是一個迭代的過程。

大家先看這幅圖。

這里典型的瀑布式設(shè)計“分析==>設(shè)計==>編碼==>測試”。這個過程每一個階段都有明確的輸入/輸出，每個階段都有一個交付件。這對我們的管理者是個福音，因為這樣子，項目的進(jìn)展一目了然，項目就可控了。所以說，這個過程是為Mananger寫的。所以，有了這句話“Oh, I write specs to keep managers happy and then code the thing the way I want “

因為，事實上，我們程序員感覺到的設(shè)計過程不是這樣的。而是這樣的：

同樣，它也是基于瀑布模型的。只是增加了一個逆向過程，使得我們在下一階段發(fā)現(xiàn)問題時，可以回過頭來修正。

我們現(xiàn)在來想想這個問題，為什么大家會說 “設(shè)計文檔沒有用”？因為作為一個過程的輸出結(jié)果，設(shè)計文檔有個致命的問題：無法保證文檔與代碼同步。表現(xiàn)在兩個方法：

1．無法保證設(shè)計文檔的結(jié)果一定會反映在代碼中（除了人去看，無法證實）。

2.設(shè)計的成果，要通過重復(fù)勞動在代碼中來表現(xiàn)。

3．后期代碼結(jié)構(gòu)的變化，很難表現(xiàn)在設(shè)計文檔中。

所以我說，設(shè)計階段的輸出應(yīng)該是一份Rose文檔和一份簡要的設(shè)計補(bǔ)充說明。這樣，我們用Rose的逆向工程能力來表現(xiàn)現(xiàn)有代碼的實際結(jié)構(gòu)/接口；用Rose的代碼生成能力來表現(xiàn)接口的修改。我們現(xiàn)在來試一下。

(Rose使用展示)

這樣，我們將模塊、類、類接口等都表現(xiàn)在Rose中，而將偽碼以注釋方式寫在代碼中。

我們少了多少事啊~~

這里附帶著強(qiáng)調(diào)一點，里程碑很重要。沒有了里程碑,迭代的設(shè)計很就成了死循環(huán)。不可控的項目也不會是好項目。

第三頁

分而治之

這是人類解決復(fù)雜問題的通用解決方法。

對應(yīng)于我們軟件設(shè)計過程，就是“產(chǎn)品?模塊?類?方法”的逐層分解過程。

其中，模塊確定了與其它模塊之間、與用戶之間的契約（模塊間公共接口）；類確定了類之間的契約(包內(nèi)公共接口)；方法確定了私有方法。下一層總是服務(wù)于上一次。

這個過程通過Rose完全能夠完成。所以，設(shè)計階段不等于寫設(shè)計文檔。設(shè)計文檔僅僅是輸出結(jié)果。

第四頁

自上而下和自下而上

這是兩種不同的思考過程。自上而上是由抽象到具體，自下而上則相反，由具體到抽象。上面提到的，分而治之，逐層分解就是一種自上而下的過程。

一般來講，自上而下比較容易點，也是軟件設(shè)計中比較提暢的一點。我們經(jīng)常強(qiáng)調(diào)的“依賴反轉(zhuǎn)”，依賴于抽象，而不是依賴于具體。都是自上而下的抽象分解過程。

那么， 在設(shè)計中還有一個關(guān)注點“分離變化點”。是我們隔離變化，將變更的影響降低的一種方法。這里就有個問題，如果你不再往下看，找出具體是什么會變化，你怎么將變化隔離封裝？這個時候，要的就是“自下而上”的分析。

佛教有一句“法無定法”，意思是說做好一件事，不一定有一個固定的法則。當(dāng)你用一種方法直不下去時，不妨試試其它方法。所以，自上而下與自下而上并不矛盾。

第五頁

原型。

設(shè)計的時候，經(jīng)常有這樣一個問題。以前沒搞過，現(xiàn)在這么做行不行呢？心里沒底。那怎么辦？寫個原型。

就在代碼中寫。需要的時候，在進(jìn)入編碼階段時，重復(fù)利用。

(比如這次我要開發(fā)個向?qū)В野l(fā)現(xiàn)有個現(xiàn)成的框架。但是不知道該怎么用，不知道能不能滿足需要。所以，我按照現(xiàn)在規(guī)格，寫了一點原型代碼。發(fā)現(xiàn)可以用。)

但是這里有個分寸的問題，就是不要寫的太多。能夠證實你的想法就可以了。一是因為咱們還有里程碑計劃，有時間點的壓力。二是因為，這部分代碼只是試驗，并不可靠，寫的越多，隱藏的問題就會越多。

第六頁

設(shè)計到什么時候結(jié)束？

下列兩個條件中滿足任意一個結(jié)束：

1. 你覺的再設(shè)計就成了寫代碼了；

2. 你沒有時間了；

第一個結(jié)束點，對各個人不一樣，只要你感覺你能寫出代碼了就行。所以，對于經(jīng)過多個版本的人可能會結(jié)束的早一些。

第二個結(jié)束點，沒有辦法的事,無論好壞，認(rèn)命，趕快把文檔搞的貌似結(jié)束，在編碼階段再嘗試補(bǔ)救。

結(jié)束