不知道大家在專案過程中寫過技術方案麼，對於專案中迭代比較大影響範圍比較大情況。可以由技術主導人在編碼之前，先出個技術方案然後在開始編碼。
出技術方案的好處是：
- 在編碼之前對此次改動有個全域性的思考，知悉這次改動的邊界和難點
- 技術方案中把具體實現邏輯和難點做了解釋，具體實現人員可以透過技術方案就知道在專案中怎麼實現。
- 如果是多人合作，可以在組內達到共識。
下面貼一個我們專案組技術方案的模板/原則。歡迎大家討論一下
整體的原則：
1. 不能脫離業務：脫離業務的架構都是耍流氓
2. 方案簡單易實現，容易落地：方案一定要簡單，簡單，簡單（重要的事情說三遍）
一. 背景
主要說明為什麼要做這次技術方案，解決什麼問題
二. 現狀
針對修改點，目前的現狀是什麼，儘量的寫涉及的細節，包括但不限於，資料實體、資料流程、技術方案等，方便評審者對現狀有所瞭解
三. 技術實現
技術方案的實現細節，說明技術方案如何實現以及如何能解決現有問題，儘量詳細，有選擇的包括以下幾點：
1. 解決問題的技術方案
- 技術架構圖
- 業務流程圖
- 實體ER圖
- 部署架構圖
2. 設計要點：強調方案設計過程中技術要點及難點
3. 技術方案的可行性分析
- 資料量：要對現有和未來一段時間的資料量有所感知，並且新的方案在預估的資料量下不會有效能問題
- 效能：原則上，新的方案一定要比老的方案效能好
- 簡單：設計要儘可能的簡單易懂
4. 如果需要新引入新的技術，需要有技術選型方案以及主流的技術或者框架對比
5. 如果有多個技術技術方案，對比各個實現方案的優缺點，並給出推薦的方案
6. 如果需要他人或系統支援：
- 指明需要別人或系統支援什麼，特別指出
- 什麼時候需要提供支援
7. 相容性考慮：新技術或者最佳化，不能直接全量上線，要考慮回滾或者異常處理
- 是否需要考慮試點，區域性試用
- 是否考慮增加開關，一旦出問題就關閉
- 是否需要做資料驗證，防止資料不一致
四. 影響範圍
技術方案對業務或者系統影響，包括不限於：
1. 修改是否影響上下游系統（內部和外部）的呼叫，是否會感知
2. 修改影響的介面（內部和外部）
3. 對程式碼修改的範圍
4. 其他
五. 解決成本
實現技術方案需要增加的成本：
1. 儲存
2. 引入新的雲服務
3. 增加機器資源
4. 其他成本
本作品採用《CC 協議》，轉載必須註明作者和本文連結