設計做到什么程度？
我說，錢多就設計的詳細，錢少就設計的粗略。
他說，也許我們可以穩定到某一個程度，不論項目大小，錢多少。
我想，大家都體驗到了UML為設計帶來的許多好處，比如交流便捷，規范開發，還有就是強迫思考，強迫我們考慮“誰是誰”和“誰做什么”。
如何使用UML，Martin Fowler在《UML Distilled Third Edition》中做了很精辟的總結，我理理自己的思路，以饗大家。
在設計精細程度上，一般有三種用法：草圖，藍圖和程序。
將UML視為草圖，著重于溝通交流，在紙上或者白板上與一群人討論，并不一定拘泥于UML的格式。我們不會討論所有要寫的程序，著眼點只在系統的部分或者某個層面。我們可以在幾個小時的開發工作前，用10分鐘交流下設計；或者用1天的時間，整理整理接下來為期兩周的迭代。
這樣的設計可能是非正式的，我們可以把白板上的照下來，把紙上的掃描下來，再加進設計文檔。使用草圖，也往往意味著我們會討論一些可能的替代性做法。所以，Martin說草圖的本質是“選擇性”。
我覺著在YXXXX項目中，用的是這樣的方式。我要求大家把接口定義出來，把主要的時序畫出來，不論是在紙上還是在Visio上，已經畫好還是現場畫。我關心的接口有兩部分，Java程序接口，主要是業務層接口，需要知道業務層暴露出哪些方法供別人調用；還有前后的數據接口，即DTO，我需要知道業務層的方法需要什么數據，會返回什么數據。我關心開發人員是否理解了調用順序，以及開發人員的工作分配，即誰做哪個類哪個方法。
將UML視為藍圖，更傾向于“完整性”。我們關注于系統的整體結構，框架層次，必須完成大的設計決策。如系統是由哪些子系統/模塊構成的，其間的聯系是什么，層次如何分布，怎樣限定層與層的通信，關鍵類的識別和關鍵方法的分配等等。
這時我們需要借助工具來完成，并遵循一些標準，比如命名方式，注釋規則，畫圖約束等等。這樣的設計一般比較正式，也可能是大多數項目所使用的。接下來，可能會繼續細化，增加類的契約，方法的契約等等；也可能直接用來開發，更進一步的設計會在寫代碼前完成。
在TXX項目中，我們便用的是這種方式。我們識別定義了主要的類方法，但并未描述業務規則和異常，并未滿足80/20法則（80%的方法和20%的類），對類和方法的描述也不是十分充分。而在實際開發過程中，藍圖更多的起指導作用，約束力比較小。
藍圖與草圖的主要區別在于：草圖強調信息通訊，而藍圖強調無所不包；草圖具有探索性質，而藍圖是定稿。
如果在藍圖的基礎上繼續設計，那么寫代碼的工作也就將越“無趣”；甚至，如果工具支持的話，我們可以在UML中完成代碼。MDA（模型驅動架構）就是基于這樣的思路。將UML視為程序語言，就需要可以把設計人員畫的圖直接生成為代碼，將寫的說明性文字生成為注釋。
目前這種方式我只是聽說過，還從沒有見過。
對于持有第一種視角的人來說，UML中最重要的是圖；而對于后兩種觀點，UML最重要的是本質（分析方法、設計方法）。
而對于概念（概念是OO的核心）理解來說，也會有兩種觀點：軟件觀點（software perspective）和概念觀點（conceptual perspective）。
持有軟件觀點的人的設計，任何UML元素（包、類、關系等等）都可以對應到軟件的實體中；而持有概念觀點的人，UML元素則對應到業務領域中的概念。
從程序員成長的設計師可能更容易具有軟件觀點；而概念觀點更容易為業務領域專家所有。
回到我們的問題上，需要將設計做到什么程度。程度必然與衡量有關，而衡量就必須有標準。通過項目的積累，我們會逐步完善這個衡量標準。
排除設計觀點的差異，忽略成本因素，與設計相關最直接的因素是：時間，作者（設計人員）和讀者（開發人員）。
毋庸置疑，時間決定了設計的程度。不同的項目有不同的時間限制，而資源也是有限的，或許我們可以根據不同的項目類型，制定不同的設計標準。
設計人員的能力決定了設計的質量，也許會因經驗不足，導致開發階段風險與成本上升。提高設計能力是我們持久的目標。
不同的開發人員，對設計的要求應該是不同的。如果是成員之間比較熟悉的團隊，草圖的方式是最便捷和有效的；如果開發人員水平參差不齊，使用藍圖不失為一個好辦法；而開發人員僅僅是傳說中的“藍領”，那么我們不得不將設計視為程序。
除此，還有很多重要的因素，如軟件開發的生命周期，需求穩定程度等等。
最后的結論是，設計可能無法穩定到一個程度，也許WQX的意思是我們可以穩定到某一種質量。
歡迎討論！
浙公網安備 33010602011771號