一些公司用cmmi做軟體開發過程管理，對詳細設計過程要求很高，需產出rose設計模型，畫出序列圖、活**等等。本意是為了讓rose設計模型對後續的編碼有指導意義。但實際實施過程中發現效果不佳，一是有人不願意認真寫詳細設計文件，二是有人不願意看詳細設計文件，問題如下：
1）當詳細設計和編碼人員實際為同一人時：既然是同一人，自己做事心裡有數，整體想清楚了就開始編碼，而不願意寫詳細設計文件。
2）當詳細設計和編碼人員不是同一人時：編碼人員根本不願意看rose設計模型，一，詳細設計要畫的很細才有效果，這樣一來要讀懂別人的序列圖、活**反而不容易；二，如果詳細設計做的不夠細，那還不如直接看需求文件。
文件有兩個功能，乙個是指導下游工序進行工作，二是作為檔案供將來回憶或新人學習之用；由於上面兩個原因，rose設計模型的第乙個功能「指導下游工序進行工作」的功能實際是失效了；而第二個功能呢？在與許多從事軟體維護工作的開發人員訪談之後，得到的結論是：大多數人更願意直接看**，而不是看詳細設計文件（因為設計文件要不就是太粗略，要不就是太細、重點不突出，看不懂）。因此rose設計文件的第二個功能也失效了。這也驗證了前人說的一句話：設計文件是一次性的，或者：**即文件。
再談談設計的目的。設計分為架構設計、概要設計、詳細設計。如果說架構設計是規劃房子的地基，概要設計則是規劃房子的鋼筋混凝土框架、詳細設計就是規劃管道、線路、門窗、外表等等（其中以管道、線路為首要）。對應到軟體上，概要設計就是要規劃出軟體的結構 —— 模組、模組之間的關係、模組內部的類（介面）、類（介面）之間的關係。而詳細設計就是規劃出軟體裡的管道、線路，可以認為是貫穿全域性的演算法。
那麼設計文件該怎麼寫呢？設計文件不是越細越好，寫得細了也沒人看，稍微發生變化又要去修改。乙個合理的設計文件是結構清晰的、重點突出的，也就是概要設計+關鍵詳細設計。概要設計是對軟體結構的描述，包括類的責任、介面的責任；關鍵詳細設計，也就是對貫穿全域性演算法思路的描述。結構的描述，用類圖就可以了。而貫穿全域性的演算法，用序列圖活**可以，用文字描述也行。說清即可，僅此足矣。那麼類裡面的屬性、方法需要在rose模型裡體現嗎？這是不必要的，有時間乙個個輸入到rose裡，不如在ide裡編碼來的直接。
設計文件如何使用？首先在設計評審時，供評委評價。其次，對詳細設計和編碼有限定作用。而詳細設計編碼最好就是同乙個人來做，可省去不必要的文件交流。在編碼完成後，設計文件的使命也就完成了。後續沒有必要維護設計編碼一致性，就算要維護一致性，因為我們的設計文件是只抓重點的，而重點的都是不容易改變的，因此維護一致性的工作量也不大。
書寫開發文件和平時隨手寫些非規範文件
現在平時寫的一些非規範文件有些亂 時間長了自己都有些看不懂。主要的開發文件就是functional spec 和 technical spec。functional spec 對映需求到功能性，technical spec 對映功能到實現。以後隨手寫一些文件的時候也依照這些要求，相對規範，比較容易將...
需求分析文件 概要設計文件 詳細設計文件
由於專案工作需要 需要提供 軟體需求規格說明書 軟體概要設計說明書 和 軟體詳細設計說明書 所以這裡整理學習一下相關文件需要的內容。文章並不設計對所有需求分析，概要設計和詳細設計的詳細描述。因為這其中的任何一點都可以單獨提取出來成為軟體工程學科中的一本書籍內容。2.1 我們為什麼需要 軟體需求規格說...
你最近在用什麼語言寫些什麼東西 V2EX
你最近在用什麼語言寫些什麼東西 v2ex 用python 寫了個某電商的 監控軟體，低於期望 自動下單，並自動通過飛信發簡訊到手機提示下單結果你最近在用什麼語言寫些什麼東西 v2ex 用go寫vps管理系統。嗯另外發現個go實現的dns伺服器，fork了下準備搞個geodns玩玩。cc cuptoo...