很多小夥伴都不知道怎麼寫詳細設計，本期就帶大家看一下詳細設計都有哪些內容。資深碼農教你寫詳細設計（附模板）
不同的公司，詳細設計不太一樣，有的細，有的粗，有的甚至沒有詳細設計。
像銀行那種乙個月上線一次的，詳設可以寫乙個星期的，不在本文討論範圍內。
像老闆說這個需求明天就要的，也不在本文討論範圍內。
詳細設計文件一般包含以下這些內容：
公司的文件一般有統一的規範格式，文件的開頭，一般要包含公司資訊、專案名稱、業務名稱、版本號等。
每個文件都應該有乙個變更歷史，即使後面可能不會再變了
這裡可以簡要描述需求，或放入需求文件的鏈結，方便隨時檢視詳細設計對應的需求。
拒絕一句話需求:
產品：下週上個新功能：登入
程式設計師：需求呢？有具體一點的嗎？
產品：就是登入啊！
程式設計師：！@#￥%……&*
有些需求很簡單，需求說完，改哪些東西，心裡就有數了。
需求分析會議一般由開發主導，在會上，需要將需求拆分出乙個乙個的功能點，功能點可以是介面，介面，整合某個技術等等。
有了功能點後，就可以大概估工時了，不過此時會估得比較粗，沒辦法，有些老闆等不到你詳細設計出來再給準確工時。
有了功能點後，就可以開始寫詳細設計了，流程圖是詳細設計裡很重要的一塊，也是開發文件中相對薄弱的一塊。
常見的有基本流程圖，時序圖，可以從前端串到後端，用不同的顏色表示。
程式設計師大多看得懂流程圖，卻畫不出流程圖
介面設計是詳細設計中非常重要的一部分，一般包含兩部分的資訊
處理邏輯：盡可能寫得詳細，讀哪些配置，查哪張表哪個字段，甚至是寫偽**
工時估得準不准，就靠這裡了寫得清不清晰了
頁面設計也是詳細設計中非常重要的一部分，一般包含幾方面的內容：
工時估得準不准，就靠這裡了寫得清不清晰了
在中大型專案中，一般都會有跑批功能，可能是每天、每週、每月，做一些資料統計，彙總，或是集中處理。
這裡的內容包括跑批的時間、週期、處理邏輯、關聯跑批等
可以考慮下面幾個問題：
這裡放入本次詳設相關的資料庫變更。
有可能是ddl，比如增加了某張表，增加了某個字段。也有可能是dml，比如相關的初始化配置，歷史資料刷庫等。
注意乙個問題：需要有另外乙個整個專案完整的資料庫設計文件。當本次迭代上線後，及時將本次變更更新資料庫文件中。
領導：給我個完整的資料庫文件
程式設計師：沒...沒有，都在各個迭代裡面了，資料庫文件好久沒維護了
領導：！@#￥%……&*
一般可以從前面的步驟中，尋找可能出現安全性問題的地方。比如
再小的迭代也可能引起效能問題，一般測試環境資料量小，很難測試效能問題。
可以從下面幾個方便考慮：
提取碼：pqnq
—————— the end ——————
碼農寫文件，其實不簡單
寫文件，本來在碼農眼中就不是什麼分內之事。真要到了趕鴨子上架的份上，碼農的各種不良反應也都來了，有的人心慌 沒底 有的人心不甘 情不願 也有的人渾身發怵心有餘悸。不同的不良反應都折射出各色碼農對於寫文件的態度。最近自己寫乙個小專案的開發文件過程中遇到不少問題，也從老大那邊學到了不少經驗，所以在此總結...
碼農寫文件，其實不簡單
寫文件，本來在碼農眼中就不是什麼分內之事。真要到了趕鴨子上架的份上，碼農的各種不良反應也都來了，有的人心慌 沒底 有的人心不甘 情不願 也有的人渾身發怵心有餘悸。不同的不良反應都折射出各色碼農對於寫文件的態度。最近自己寫乙個小專案的開發文件過程中遇到不少問題，也從老大那邊學到了不少經驗，所以在此總結...
碼農寫文件，其實不簡單
寫文件，本來在碼農眼中就不是什麼分內之事。真要到了趕鴨子上架的份上，碼農的各種不良反應也都來了，有的人心慌 沒底 有的人心不甘 情不願 也有的人渾身發怵心有餘悸。不同的不良反應都折射出各色碼農對於寫文件的態度。最近自己寫乙個小專案的開發文件過程中遇到不少問題，也從老大那邊學到了不少經驗，所以在此總結...