但是現(xiàn)實(shí)的情況真的如此嗎？我們來反思一下：

(1)詳細(xì)設(shè)計和代碼的吻合程度有多高？

假設(shè)在項(xiàng)目中，代碼在測試后修改完畢提交后，并不修改詳細(xì)設(shè)計，則詳細(xì)設(shè)計和代碼之間并不吻合，并且很大程度上，吻合度會非常低。

如果詳細(xì)設(shè)計和最終的代碼并不吻合，那么這樣的詳細(xì)設(shè)計并不能給將來的維護(hù)帶來任何幫助。

如果詳細(xì)設(shè)計并不能給后續(xù)帶來幫助，為什么要書寫它呢？

因?yàn)?mdash;—詳細(xì)設(shè)計是用來指導(dǎo)代碼書寫的。

(2)詳細(xì)設(shè)計對代碼的指導(dǎo)意義有多大？

詳細(xì)設(shè)計的類圖是用來定義類框架之間的關(guān)系的；其中的時序圖（有時也用流程圖）是用來定義方法之間的調(diào)用關(guān)系的。

如果說詳細(xì)設(shè)計是這么定義的，那么為什么不直接用IDE寫成代碼形式？

因?yàn)?mdash;—詳細(xì)設(shè)計的過程是需要記錄文檔以備后查的。

(3)詳細(xì)設(shè)計是怎么復(fù)查和修改的？

詳細(xì)設(shè)計的復(fù)查是通過對書寫完成的詳細(xì)設(shè)計文檔進(jìn)行閱讀和審查，并指出其中可能出現(xiàn)的錯誤和遺漏。

然后針對提出的問題進(jìn)行修改，直到修改完成為止。

為什么要這樣復(fù)查和修改呢？因?yàn)樵敿?xì)設(shè)計的質(zhì)量提高有助于早期發(fā)現(xiàn)問題。

(4)既然詳細(xì)設(shè)計是用來指導(dǎo)代碼書寫的，為什么還需要后續(xù)的測試？

換句話說，為什么詳細(xì)設(shè)計不能夠100%正確。

這么問并不是要求把詳細(xì)設(shè)計100%書寫正確——因?yàn)檫@是個不可能的任務(wù)。

詳細(xì)設(shè)計是一個猜想的過程，其復(fù)查和修改也都是在猜測中完成的。

詳細(xì)設(shè)計到底做成什么樣才能夠更有效地指導(dǎo)代碼書寫呢？

(5)詳細(xì)設(shè)計的完成是怎么定義的？

詳細(xì)設(shè)計的完成指標(biāo)是：詳細(xì)設(shè)計的頁數(shù)達(dá)到若干頁，每頁復(fù)查發(fā)現(xiàn)的問題達(dá)到多少個。

詳細(xì)設(shè)計是用來指導(dǎo)代碼書寫的。為什么不從指導(dǎo)代碼書寫的方面進(jìn)行指標(biāo)定義？

詳細(xì)設(shè)計還有問題殘留的時候怎么就開始代碼書寫了？

現(xiàn)實(shí)情況是：詳細(xì)設(shè)計的完成是以項(xiàng)目經(jīng)理的喜好決定的——往往是時間壓力決定的，還有時間就繼續(xù)寫；沒有時間就算完成了。

(6)為什么覺得詳細(xì)設(shè)計是必要的過程？

因?yàn)槭且?guī)定的。因?yàn)閯e人都這么做。這應(yīng)該不是答案吧？

那么到底應(yīng)該怎么書寫詳細(xì)設(shè)計呢？答案是：不寫！理由如下：

(1) 詳細(xì)設(shè)計的職責(zé)不明確

詳細(xì)設(shè)計名將概要設(shè)計細(xì)化，并指導(dǎo)代碼書寫。但是反觀其階段結(jié)束時間不明確，并且階段結(jié)束的判定標(biāo)準(zhǔn)也沒有對如何指導(dǎo)代碼書寫進(jìn)行定義，很難說詳細(xì)設(shè)計真的是用來指導(dǎo)代碼書寫還是將概要設(shè)計細(xì)化的。

(2) 詳細(xì)設(shè)計沒有生產(chǎn)有價值的產(chǎn)物。

據(jù)統(tǒng)計，詳細(xì)設(shè)計在項(xiàng)目開發(fā)過程中所消耗的工時基本上占編碼和單元測試的一半。但是它的產(chǎn)物——UML圖可以通過直接書寫代碼，然后從IDE導(dǎo)出生成，這個過程只需要幾秒鐘。

但是詳細(xì)設(shè)計還是要做的。這不是和前面矛盾嗎？不！

上面說的是寫，這里說的是做。

有些處理的條件很多，不是三言兩語能夠說清楚的，這時候就需要詳細(xì)設(shè)計。

比如：一個由兩組條件決定的處理。從需求角度山來說，通過畫成二維表可以描述清楚其各個條件組合下的行為
                 a        b      c
         1      a1     b1     c1
         2      a2     b2     c2
         3      a3     b3     c3

針對這種情況，如果寫流程圖，那么代碼也將會按照流程圖那么書寫，代碼會變得很冗長。所以流程圖并不適合做詳細(xì)設(shè)計。這種情況可以通過類的書寫來完成。

假設(shè)行條件是時間范圍(TimeScope)，分別代表過去(Past)，現(xiàn)在(Present)和將來(Future)而列條件是狀態(tài)(State)，分別代表申請(Apply)，批準(zhǔn)(Approval)和拒絕(Decline)

在類的設(shè)計時，以時間范圍為主軸，狀態(tài)為輔軸，那么類定義為:

interface TimeScope { 
      public void apply(); 
      public void approval(); 
      public voi decline(); 
} 

則Past，Present和Future分別實(shí)現(xiàn)相應(yīng)的方法就可以實(shí)現(xiàn)上面需求定義的矩陣。

這種方法叫做橋接模式(Bridge Pattern)

而這個過程并不需要留下文檔。

同樣大多數(shù)情況來說，根據(jù)需求可以直接生成代碼。而詳細(xì)設(shè)計是一個可以簡化到只要幾分鐘就可以完成的過程。并且，從質(zhì)量的角度來說，并沒有損失。

設(shè)想一下，如果一個項(xiàng)目可以略掉詳細(xì)設(shè)計過程，其可以帶來的節(jié)省有多大。

如果客戶非要要求詳細(xì)設(shè)計怎么辦？

雇傭比軟件工程師便宜的文檔人員來根據(jù)代碼反寫詳細(xì)設(shè)計——因?yàn)轭悎D都可以通過工具生成——所以，所需要的文檔人員也很少，工時也很少。