詳細設計是V模型或者瀑布開發中的一個重要的環節。這個階段負責把概要設計進行細化,並為代碼書寫作出指導。可以說是一個承上啟下的重要環節。
但是現實的情況真的如此嗎?我們來反思一下:
(1)詳細設計和代碼的吻合程度有多高?
假設在項目中,代碼在測試後修改完畢提交後,並不修改詳細設計,則詳細設計和代碼之間並不吻合,並且很大程度上,吻合度會非常低。
如果詳細設計和最終的代碼並不吻合,那麼這樣的詳細設計並不能給將來的維護帶來任何協助。
如果詳細設計並不能給後續帶來協助,為什麼要書寫它呢?
因為——詳細設計是用來指導代碼書寫的。
(2)詳細設計對代碼的指導意義有多大?
詳細設計的類圖是用來定義類架構之間的關係的;其中的時序圖(有時也用流程圖)是用來定義方法之間的調用關係的。
如果說詳細設計是這麼定義的,那麼為什麼不直接用IDE寫成代碼形式?
因為——詳細設計的過程是需要記錄文檔以備後查的。
(3)詳細設計是怎麼複查和修改的?
詳細設計的複查是通過對書寫完成的詳細設計文檔進行閱讀和審查,並指出其中可能出現的錯誤和遺漏。
然後針對提出的問題進行修改,直到修改完成為止。
為什麼要這樣複查和修改呢?因為詳細設計的品質提高有助於早期發現問題。
(4)既然詳細設計是用來指導代碼書寫的,為什麼還需要後續的測試?
換句話說,為什麼詳細設計不能夠100%正確。
這麼問並不是要求把詳細設計100%書寫正確——因為這是個不可能的任務。
詳細設計是一個猜想的過程,其複查和修改也都是在猜測中完成的。
詳細設計到底做成什麼樣才能夠更有效地指導代碼書寫呢?
(5)詳細設計的完成是怎麼定義的?
詳細設計的完成指標是:詳細設計的頁數達到若干頁,每頁複查發現的問題達到多少個。
詳細設計是用來指導代碼書寫的。為什麼不從指導代碼書寫的方面進行指標定義?
詳細設計還有問題殘留的時候怎麼就開始代碼書寫了?
現實情況是:詳細設計的完成是以專案經理的喜好決定的——往往是時間壓力決定的,還有時間就繼續寫;沒有時間就算完成了。
(6)為什麼覺得詳細設計是必要的過程?
因為是規定的。因為別人都這麼做。這應該不是答案吧?
那麼到底應該怎麼書寫詳細設計呢?答案是:不寫!理由如下:
(1) 詳細設計的職責不明確
詳細設計名將概要設計細化,並指導代碼書寫。但是反觀其階段結束時間不明確,並且階段結束的判定標準也沒有對如何指導代碼書寫進行定義,很難說詳細設計真的是用來指導代碼書寫還是將概要設計細化的。
(2) 詳細設計沒有生產有價值的產物。
據統計,詳細設計在項目開發過程中所消耗的工時基本上占編碼和單元測試的一半。但是它的產物——UML圖可以通過直接書寫代碼,然後從IDE匯出產生,這個過程只需要幾秒鐘。
但是詳細設計還是要做的。這不是和前面矛盾嗎?不!
上面說的是寫,這裡說的是做。
有些處理的條件很多,不是三言兩語能夠說清楚的,這時候就需要詳細設計。
比如:一個由兩組條件決定的處理。從需求角度山來說,通過畫成二維表可以描述清楚其各個條件組合下的行為
a b c
1 a1 b1 c1
2 a2 b2 c2
3 a3 b3 c3
針對這種情況,如果寫流程圖,那麼代碼也將會按照流程圖那麼書寫,代碼會變得很冗長。所以流程圖並不適合做詳細設計。這種情況可以通過類的書寫來完成。
假設行條件是時間範圍(TimeScope),分別代表過去(Past),現在(Present)和將來(Future)
而列條件是狀態(State),分別代表申請(Apply),批准(Approval)和拒絕(Decline)
在類的設計時,以時間範圍為主軸,狀態為輔軸,那麼類定義為:
interface TimeScope {
public void apply();
public void approval();
public voi decline();
}
則Past,Present和Future分別實現相應的方法就可以實現上面需求定義的矩陣。
這種方法叫做橋接模式(Bridge Pattern)
而這個過程並不需要留下文檔。
同樣大多數情況來說,根據需求可以直接產生代碼。
而詳細設計是一個可以簡化到只要幾分鐘就可以完成的過程。並且,從品質的角度來說,並沒有損失。
設想一下,如果一個項目可以略掉詳細設計過程,其可以帶來的節省有多大。
如果客戶非要要求詳細設計怎麼辦?
僱傭比軟體工程師便宜的文檔人員來根據代碼反寫詳細設計——因為類圖都可以通過工具產生——所以,所需要的文檔人員也很少,工時也很少。