最近看了一篇文章，文章中提到在開發流程中包含一個設計方案的階段，位於需求評審之后，用於描述自己對於該需求的實現思路、模塊划分等相關考慮的點，可供今后自己或他人查閱。
目的就是在編碼前理清思路，整體架構，查缺補漏，作為他人或自己的技術參考文檔。
自己在項目開發的過程中，也曽有過這樣類似的想法，但沒有作者那樣寫的系統，也沒有在團隊中落地。
基於文章中的設計方案，自己做了點修改。設計方案包括4個部分：需求、調研、實現和復盤。
1）需求
在設計方案的開頭，列出相關人員（便於精確找人），需求信息和各類時間。
需求背景：因為我們要做線下推廣，提高xxxxxxxxx PRD：產品文檔鏈接 產品：老吳 UI：梨子 測試：小木 前端：雋雋 服務端：必煦 聯調時間：2021.07.30 提測時間：2021.07.31 上線時間：2021.08.10
2）調研
功能的技術選型，對比不同方案的優缺點，適當取舍，形成一套適合當前場景的最優方案。
以復雜動畫為例：
- 自己之前有沒有做過類似的動畫，可以借鑒？
- 公司內部有沒有自制的動畫庫，可以引用？
- 業界有沒有現成的動畫庫或不錯的實現思路，可以參考？
- 用原生實現，與遇到哪些問題，兼容會不會很困難？
- .........
3）實現
需要思考很多方面：業務的完整流程、數據結構的設計、關鍵功能的邏輯描述、異常處理、安全、性能、與現有業務的耦合情況、組件復用等。
保證自己和他人在看到這份方案時，能清楚明白你的設計思路、代碼意圖和模塊划分。
可用任意方式表達自己的思路，例如偽代碼、圖表或純文字等。
流程圖讓自己和他人對需求有個直觀的了解。
偽代碼在不寫具體代碼前，展示自己的編碼思路，傳達代碼意圖，即使是不會代碼的人也能讀懂，給你點意見。
function getSomeData() { let data; if(無緩存) { // 請求數據 if(請求異常) // 展示錯誤頁面; data = 請求到的數據; } // 展示頁面 }
模塊划分是架構的一個點，需要考慮哪些是獨立模塊、哪些是公共模塊、哪些是與業務耦合的模塊。
用例圖可整理出大大小小的場景，在列出后就會發現流程中缺少的部分，以及各種未考慮到的邊界。
還有安全問題，例如防止惡意的接口訪問。頁面中是否有性能問題。未來若擴展需求，那么當前設計的擴展性是否能滿足需求的變化。
4）復盤
復盤總結的內容可自由發揮，按照自己的實踐，記錄與需求相關的一切，例如：
- 撰寫方案時遇到的問題，以及解決方案。
- 代碼上線后，收到的反饋，做的好的方面和做的差的方面。
- 別人在做設計方案時，有什么值得學習的地方。
- 在整個項目開發中，流程中的哪個點處理的不好（例如低效無用的溝通等），之后討論改進方案。
- .........