**：
rd需要撰寫的設計文件主要分為：總體設計文件 + 詳細設計文件，後簡稱為「總設」+「詳設」。
總設和詳設都應該包含的部分：
（1） 需求：一般以產品的語言描述，這一塊可以拷貝產品需求文件中的story list部分；
（2） 名詞解釋（可選）：非相關領域內的同學需要看到文件需要提前了解的一些概念性質的東西；
（3） 設計目標：又分為功能目標和效能目標，功能目標一般是對產品需求的技術描述，效能目標是根據產品給出的資料對效能進行的評估。一般來說，新服務必須要有效能目標一項，效能目標可能會影響設計方案。
除了都應該包含的部分，總體設計一般還包含：
（1） 系統架構：一般來說會有個簡單的架構圖，並配以文字對架構進行簡要說明；
（2） 模組簡介：架構圖中如果有很多模組，需要對各個模組的功能進行簡要介紹；
（3） 設計與折衷：設計與折衷是總體設計中最重要的部分。
（4） 潛在風險（可選）；
輸出總體設計的時候，很多方案還是不確定的，需要在設計評審會議上確認。
總體設計重點在「方案折衷」，總體設計評審完畢之後，此時應該是所有方案都確認了，需要輸出各模組的詳細設計，詳細設計重點在「詳細」：
（1） 總體設計結論彙總（可選）：總體設計上達成一致的結論有個簡要概述，說明詳設是對這些結論的實現；
（2） 互動流程：簡要的互動可用文字說明，複雜的互動建議使用流程圖，互動圖或其他圖形進行說明；
（3） 資料庫設計：這個是應該放在總設還是詳設呢？
（4） 介面形式：有了資料庫+介面+流程，別的同學拿到詳設文件，基本也能夠搞定了；
（5） 其他細節：例如公式等；
理論上輸出了詳細設計之後，無論誰拿到了這個詳設文件，都是能夠完成該項目的。
個人實踐分享：
一、 大圖
（1） 大系統或複雜流程，其架構圖或者流程圖會非常大，經常比a4紙或word的一頁大很多，此時不宜在word中直接貼圖形，貼了也看不清，建議將圖放在wiki上，文件中直接貼鏈結；
（2） 一定要儲存viso或者其他圖形的原始檔，否則今後改動起來要重畫，代價可想而知；
二、 設計與折衷
（1） 設計與折衷是總設中最重要的內容，總設評審中，主要就是討論這些折衷的優劣；
（2） 評審過後，不但要郵件周知結論，還要在總設中進行更新，說明最終決定使用了哪種方案，為什麼使用這種方案；根據自己的經驗，接手別人的模組、專案，拿到**和文件，設計方案對我來說完全是個謎！！！
（3） 有時候因為排期或者其他原因，不一定採用了最優的設計方案，此時更應該在總設中記錄越策的過程與原因；
（4） 最後，設計折衷是乙個很好的自我辯解的機會：因為專案進度，或者歷史遺留問題，我不得不採取了乙個這樣的設計，不要再罵我了。
三、 效能目標
效能目標是新模組文件必不可少的一部分，很多專案對效能影響較大的話，也必須撰寫效能目標，效能一般來說可能包含以下部分：
（1） 日平均請求：一般來自產品人員的評估；
（2） 平均qps：日平均請求 除以 4w秒得出，為什麼是4w秒呢，24小時化為86400秒，取使用者活躍時間為白天算，除2得4w秒；
（3） 峰值qps：一般可以以qps的2~4倍計算；
我們在做壓力測試時，需要關注壓力達到「峰值qps」時，伺服器的cpu，記憶體，io，net等等伺服器效能引數。
TypeSDK總體設計思路和架構
引言 本文旨在提供讀者製作乙個自己的聚合sdk的思路，拋磚引玉，讓更多的讀者對聚合sdk有好的理解。這是最好的時代，這是最壞的時代，這是智慧型的時代，這是愚蠢的時代 這是信仰的時期，這是懷疑的時期 這是光明的季節，這是黑暗的季節 這是希望之春，這是失望之冬 人們面前有著各樣事物，人們面前一無所有 人...
如何撰寫軟體詳細設計內容？
1.1 編寫目的 說明編寫詳細設計方案的主要目的。說明書編制的目的是說明乙個軟體系統各個層次中的每個程式 每個模組或子程式 和資料庫系統的設計考慮，為程式設計師編碼提供依據。如果乙個軟體系統比較簡單，層次很少，本檔案可以不單獨編寫，和概要設計說明書中不重複部分合併編寫。方案重點是模組的執行流程和資料...
如何寫詳細設計文件
在大多數軟體專案中，要末不作詳細設計，要麼開發完成後再補詳細設計文件，質量也不容樂觀，文件與系統往往不能同步，使詳細設計文件完全流於形式，對工作沒有起到實際的幫助。那到底應不應該寫詳細設計文件呢，怎麼使詳細設計文件起到他應有的作用呢，下面就讓我們來認識一下詳細設計及寫詳細設計文件的好處和問題。什麼是...