以前寫業務，評審完，感覺需求理解得差不多就開擼，不怎么會做詳細設計。
大部分情況還好，遇到復雜交互，就歇菜了，組件寫着寫着，接口變動，得配合后端魔改，強行寫一些邏輯，導致代碼耦合嚴重。
如果遇到開發工時較少的，那真的就是能跑就行，可維護性，可擴展，代碼質量根本顧不上了。
為什么系統到后來改不動了，出現巨石屎山項目，沒做好設計也是其中一個原因。
所以，現在稍微復雜的頁面，或者交互，我都會提前設計一下，在項目立項之后，就開始技術調研，提前跟產品，后端溝通好一些前提條件，對於一些重要的外部組件、庫和服務，在文檔中詳細記錄資料及用法，后面就是堆代碼，擼起來會很開心。
類似把一團纏繞的線，前面理清以后，后面直接編織即可，不用編織一下理一下線，效率高了，也能保證高質量。（對，我就是這樣保證產出的高質量噠～）
下面總結一下：
不做設計的壞處：
- 開發時才發現有些沒提前想到的事情，導致速度慢，效率低，經常Delay、返工。
- 新人來了沒有可參考的文檔，不好理解當前的項目，難以上手。
- 技術方案沒有文檔沉淀，其他團隊也難以借鑒和復用。
做設計目標：
- 提升開發效率，以及程序的可維護性。
- 提升團隊成員內架構設計能力。
- 通過技術設計和各種方案的不斷優化，增強全公司的前端技術能力，提高產物的復用性。
設計注意事項：
- 需求是否相符：評判技術設計文檔與產品需求是否相符，主要體現在功能、性能、安全性方面。
- 實現是否合理：主要體現在可擴展性、實現成本、對接成本方面。
- 在需求變更、后端接口發生較大變化，或其他因素使得前端方案改變時，需要及時修改設計文檔。
實踐：
之前寫的設計，截取部分（獲得產研老大，架構老大點贊）：
設計模版
設計要考慮哪些呢？
-
需求說明
可以簡單介紹需求，把PRD帖過來。
功能需求
性能需求
安全需求
- 名詞解釋
- 數據層
數據調用層的設計，這里要明確說明后端接口的風格，如何調用。
-
整體設計
-
技術選型，為什么用這些技術，有什么好處、壞處，可以持續用多久，是否在產品的生命周期內一直用，還是未來需要重構……
-
程序整體架構圖，技術實現的粗粒度體現。
-
整個項目/產品的模塊如何拆分的，層次結構是怎樣的。如果比較復雜，就用圖體現一下。
-
整個項目的主要業務流程，可以體現在架構圖中，也可以單獨畫一個流程圖。
- 外部依賴
其他非業務的依賴，如第三方公共庫，如何調用，如何傳參數…… 可以把相關文檔貼過來。
- 業務API依賴
與后端的對接方式，貼上接口文檔地址。
前端的數據層實現方案，用什么網絡庫調用接口？
-
詳細設計
-
每個模塊的詳細說明。有些模塊要是簡單，沒啥可講的，直接做的那種，可以不用寫啥。與以前項目中的差不多的，也貼個鏈接。
-
復雜模塊，要畫架構圖、流程圖。
-
特別的技術方案。如果有復雜的算法，或者視覺、動畫效果，可以在此寫一下實現方案。
- 部署、運維
如果有必要，畫出部署圖。
- 性能優化和保障
- 安全防護和保障
學習一下大型項目的架構
https://repository.genmymodel.com/qa4862741/netty
https://blogwavi.wordpress.com/react-class-diagram/
https://thenewstack.io/microservices-node-js/
畫架構圖，可以參考C4模型：https://c4model.com/
