本文將介紹寫技術(shù)方案的意義，如何評判技術(shù)方案的好壞，如何寫好技術(shù)方案。

寫技術(shù)方案的意義

寫技術(shù)方案根本目的是提高研發(fā)效率和質(zhì)量，具體體現(xiàn)在以下方面：

1、提高溝通效率
對于整個團隊，通過技術(shù)方案文檔和評審對齊提高溝通效率：

• 產(chǎn)品經(jīng)理可以審查技術(shù)方案是否與產(chǎn)品設計有偏差，是否滿足當前產(chǎn)品需求和后續(xù)產(chǎn)品設計規(guī)劃；
• 開發(fā)leader可以把控方案是否滿足技術(shù)要求，包括技術(shù)規(guī)范，性能要求，實現(xiàn)復雜度，可拓展性等；
• 測試同學可以掌握需求技術(shù)實現(xiàn)原理，改動點，影響點，再做針對性測試用例設計；
• 后續(xù)接手項目的同學可以通過技術(shù)方案文檔熟悉系統(tǒng)。

2、提高開發(fā)效率和質(zhì)量
對于開發(fā)同學，通過寫技術(shù)方案，把需求和實現(xiàn)提前梳理一遍，減少等到編碼階段才發(fā)現(xiàn)前期考慮不全導致返工的情況；并且寫好技術(shù)方案再編碼，使得編碼時思維更加清晰，提高編碼效率和質(zhì)量。

怎么樣才是好的技術(shù)方案

怎么樣才算是好的技術(shù)方案，至少需要滿足下面3個條件：

1 思路清晰

在講技術(shù)需求時，常見的問題是一上來直接給出解決方案，導致受眾不能理解為什么要這樣設計。其實相比解決方案，更重要的是怎么思考的，思考的過程非常重要。思路就是思考的線索，思路清晰的方案，層次分明，讓受眾快速理解清楚。

整個技術(shù)方案思考的線索可以用5W2H分析法串起來：Why、Who、When、Where、What、How 和 How much（如下圖所示），從七個方面去分析思考：

整個技術(shù)方案需要先基于需求背景，定義清楚要解決的問題，明確目標，搞清楚 Why。定義清楚問題之后，再從When，What，Where，How等不同的角度，對問題進行分析和解決，先講整體架構(gòu)，再細化流程，先主線，再分支，先正常鏈路，再異常鏈路。

2 滿足需求

技術(shù)方案滿足的需求包括功能需求和質(zhì)量需求。
功能需求不僅是當前產(chǎn)品提出的功能需求，還要對未來需求的擴展有一定的規(guī)劃，預留好擴展點，這就要求開發(fā)在規(guī)劃設計前，對現(xiàn)狀和需求進行充分的收集和分析。

除了功能需求，更考驗開發(fā)同學技術(shù)實力的是質(zhì)量需求，包括異常處理，降級方案，灰度方案，運維方案，高可用設計。設計時要結(jié)合具體業(yè)務場景，當前項目階段，做合理的權(quán)衡，避免陷入極端：或面面俱到，過度設計；或方案過粗，考慮不周。

3 可實施

可以這樣評估一個技術(shù)方案是否可實施：技術(shù)方案完成之后，其他人能否照著技術(shù)方案按時按質(zhì)完成開發(fā)并上線？
有的技術(shù)方案看似高大上，高瞻遠矚，開發(fā)實施起來卻困難重重，常見原因如下：

• 不夠細：涉及改動的字段，報文，異常情況，邊界情況，歷史數(shù)據(jù)兼容等處理沒說明清楚
• 做不完：方案做的調(diào)整過大，雖然能解決問題，但是實施起來時間不夠

在寫技術(shù)方案時，方案需要足夠完善詳細，把開發(fā)涉及的關(guān)鍵點考慮完善，這些點沒有先界定清楚的話，開發(fā)的時候容易才發(fā)現(xiàn)跟系統(tǒng)當前現(xiàn)狀有沖突，或者開發(fā)出來偏離方案設計。

方案的設計也要考慮時間，開發(fā)成本，是否符合系統(tǒng)現(xiàn)狀、團隊可調(diào)配的資源，有些方案從技術(shù)的角度是最佳，但是從實施的角度并非最佳，例如會額外引入上下游系統(tǒng)相應的改動，帶來一定的溝通協(xié)作成本。所以方案設計在考慮產(chǎn)品和技術(shù)等限制的同時，也需要考慮當前現(xiàn)狀，要求的上線時間等其他因素，選擇最合適的技術(shù)方案?？梢栽诜桨钢袑懖煌膶崿F(xiàn)的評估對比，進行取舍權(quán)衡，或者方案拆成不同的開發(fā)實施階段。

方案的組成

做技術(shù)方案設計的前提條件是，定義清晰的業(yè)務流程，明確的期望拿到的預期結(jié)果。技術(shù)方案的各個組成部分圍繞整個產(chǎn)品的研發(fā)周期，用一張圖總結(jié)如下：

1 需求說明

為什么產(chǎn)品文檔介紹過需求，技術(shù)方案里面還要寫需求說明？主要原因如下：

• 介紹需求：通過在技術(shù)方案里面簡明扼要介紹產(chǎn)品需求，有利于其他看技術(shù)方案的人快速理解需求，后面具體技術(shù)實現(xiàn)的出發(fā)點。
• 對齊需求：需求說明部分體現(xiàn)了開發(fā)同學對產(chǎn)品需求的理解，在技術(shù)評審階段進一步與產(chǎn)品同學檢查對齊一遍，減少理解出現(xiàn)偏差。

需求說明包括需求背景和需求拆解：

(1) 需求背景
說明為什么需要做這個需求，需求的價值意義是什么。

(2) 需求拆解
從需求實現(xiàn)的維度對需求拆解成相對各自獨立子需求，并概要地說明每個子需求要做哪些內(nèi)容，可以依據(jù)實際情況按照不同的角度來拆解，常見拆解的角度有：

• 實現(xiàn)的步驟流程
• 功能模塊、業(yè)務領域
• 對外提供的接口、服務

2 概要設計

思路不清晰的技術(shù)方案有一個常見的問題：在交代完需求背景之后，就直接開始介紹每個子需求的具體實現(xiàn)。這種技術(shù)方案各個部分比較分散細碎，沒有統(tǒng)一成整體，閱讀起來并不好把握，這些設計背后的思路是什么，為什么要這樣設計。

概要設計包括系統(tǒng)現(xiàn)狀，總體思路和系統(tǒng)架構(gòu)。
(1) 系統(tǒng)現(xiàn)狀
為什么需要寫系統(tǒng)現(xiàn)狀？一方面是有些產(chǎn)品需求文檔涉及系統(tǒng)現(xiàn)狀這塊并不清晰，例如需求文檔寫成“在系統(tǒng)當前實現(xiàn)邏輯的基礎上，進行xxx調(diào)整”，因此需要在技術(shù)方案對系統(tǒng)現(xiàn)狀進行補充說明。另一方面，介紹系統(tǒng)現(xiàn)狀能方便理解后續(xù)設計的出發(fā)點，在技術(shù)評審時方便評估當前設計的合理性以及是否有遺漏的點。

系統(tǒng)現(xiàn)狀可以針對需求的內(nèi)容，需求影響點來介紹，常見的內(nèi)容可以介紹系統(tǒng)當前處理邏輯，歷史數(shù)據(jù)的數(shù)據(jù)量，請求量，數(shù)據(jù)增長量等情況。寫系統(tǒng)現(xiàn)狀時，不需要面面俱到，而是結(jié)合當前需求，針對性地重點介紹與需求相關(guān)系統(tǒng)的情況，為接下來介紹總體思路，系統(tǒng)架構(gòu)做鋪墊，其他不太相關(guān)的現(xiàn)狀可以簡單帶過或者不介紹。

(2) 總體思路
寫總體思路可以為后面介紹整個詳細解決方案奠定基礎：對方案進行信息壓縮，后面的詳細方案介紹都是圍繞著總體思路進行展開，使得整個方案閱讀起來方向明確，思路清晰。總體思路的內(nèi)容是概括性介紹需求實現(xiàn)涉及關(guān)鍵問題的解決方案。

(3) 系統(tǒng)架構(gòu)
概要設計中的系統(tǒng)架構(gòu)是總體思路進一步補充，說明系統(tǒng)總體上的架構(gòu)設計，畫系統(tǒng)架構(gòu)圖是介紹清楚系統(tǒng)架構(gòu)的有效手段。在概要設計中的架構(gòu)與詳細設計中的架構(gòu)的關(guān)鍵區(qū)別在于，前者關(guān)注系統(tǒng)整體處理，后者關(guān)注子需求的具體實現(xiàn)。在概要設計中介紹的架構(gòu)圖常見的歸類有：

• 按照系統(tǒng)模塊和處理流程介紹，介紹各個模塊處理的步驟，系統(tǒng)間的交互。
• 按層級介紹，把具有相同屬性或特征的信息塊歸為同一個層級，例如系統(tǒng)MVC分層架構(gòu)。

畫圖時，注意不要想在一張圖里面做到面面俱到，畫之前要想清楚這張圖要表達什么內(nèi)容，傳遞什么信息，再針對性來畫，不同的類型的圖不要合在一起。例如想說明系統(tǒng)的部署結(jié)構(gòu)，用部署圖，說明業(yè)務的主要流程，用流程圖；如果圖里面，既有系統(tǒng)部署涉及的基礎組件，又有業(yè)務處理流程，圖表現(xiàn)出來的信息就比較混亂。

3 詳細設計

詳細設計可分成開發(fā)約定，功能實現(xiàn)，可維護性設計，可靠性設計，方案選擇。

(1) 開發(fā)約定
開發(fā)約定部分常見介紹的內(nèi)容如下：

• 方案新引入的名詞，概念的解釋，方便后面的內(nèi)容引用。
• 前期上下游對接達成一致的約定/協(xié)議。

(2) 功能實現(xiàn)

軟件系統(tǒng)工作的核心功能是對數(shù)據(jù)的處理。因此在技術(shù)方案介紹具體功能實現(xiàn)時，重點關(guān)注的點是數(shù)據(jù)鏈路，包括：

• 數(shù)據(jù)源：系統(tǒng)的流量來源、業(yè)務在何時何地觸發(fā)，例如對外提供的接口，定時任務，MQ消費等
• 計算轉(zhuǎn)換：數(shù)據(jù)如何做轉(zhuǎn)換運算，加工處理的流程
• 存儲：數(shù)據(jù)存儲設計

為了介紹整個數(shù)據(jù)處理流程，體現(xiàn)在以下方面：

• 接口設計：提供接口設計文檔，包括入?yún)⒊鰠⒆侄味x，接口參數(shù)校驗邏輯，異常情況的處理和返回的錯誤碼。
• 系統(tǒng)間交互流程：結(jié)合系統(tǒng)間流程圖說明整筆業(yè)務請求涉及哪些系統(tǒng)組成部分，業(yè)務的發(fā)起來源，系統(tǒng)間交互調(diào)用了具體哪個接口，請求處理基本步驟和數(shù)據(jù)落地存儲邏輯。
• 系統(tǒng)內(nèi)處理流程：結(jié)合業(yè)務處理流程圖說明請求如何加工計算數(shù)據(jù)，處理的具體步驟，最終處理完成之后結(jié)果如何保存，或者傳輸?shù)绞裁吹胤健?/li>
• 存儲設計，包括存儲結(jié)構(gòu)（包括MySQL、ES、Redis、OSS等）設計，包括表和字段的概念定義，各個表之間的關(guān)聯(lián)，業(yè)務系統(tǒng)如何使用這些庫表。

(3) 可維護性設計

可維護性設計關(guān)注的是后續(xù)系統(tǒng)的迭代升級，需求變更，系統(tǒng)怎么維護的問題。這塊的關(guān)鍵點主要是代碼復雜度問題，不好維護的系統(tǒng)，會因為系統(tǒng)引入一個新需求，整個系統(tǒng)需要做大量改動。因此系統(tǒng)需要考慮通過提前做一些可拓展設計方便后續(xù)維護，體現(xiàn)在以下方面：

• 拓展點分析：結(jié)合產(chǎn)品需求分析后續(xù)擴展帶來的變化點，為了支持這些變化系統(tǒng)需要預留哪些擴展點。
• 系統(tǒng)建模：針對變化點，對系統(tǒng)對象進行建模，主要關(guān)注：模塊（職責明確的模塊或者組件）、關(guān)系（組件間明確的關(guān)聯(lián)關(guān)系）、邊界（約束和指導原則）。
• 設計模式：使用設計模式時，要注意設計模式的底層邏輯是“找到變化，封裝變化”，將變化封裝在可控范圍內(nèi)，具體介紹設計模式涉及的類圖，以及拓展新需求時，系統(tǒng)需要做的變動。
• 配置項：包括配置項的具體定義，使用注意事項。

(4) 可靠性設計

可靠性設計包括以下要點：
灰度方案
如果是新系統(tǒng)初步上線用于替代老系統(tǒng)，新系統(tǒng)還需要經(jīng)過進一步線上驗證，這時需要考慮灰度方案，包括灰度的周期計劃，灰度的范圍/維度，灰度配置策略。

容量評估
容量評估需要根據(jù)請求量，評估要預留給程序多少相應的運行資源。包括內(nèi)存，磁盤，CPU，存儲服務等。
評估的點包括：接口平均QPS、峰值QPS、接口請求和返回報文大小，消息隊列的平均消息數(shù)、峰值消息數(shù)、報文大小。這一部分如果是改動的業(yè)務，可以參考以前的監(jiān)控，如果是新業(yè)務或者新活動可以跟運營、產(chǎn)品確定業(yè)務量。若預估峰值會很高，需要進行壓測。

監(jiān)控報警
當方案不確定性比較大，容易出錯，一旦出錯造成的影響較大，需要加監(jiān)控告警，說明的信息包括：模塊，監(jiān)控指標，監(jiān)控閾值，報警方式等。

(5) 方案選擇
當我們設計了一個方案之后，評估這個方案是不是最優(yōu)方案最簡單的辦法，就是看看還有沒有更優(yōu)的方案。
不同方案如何做評估選擇？可以做360度全面評估對比，具體的操作方式為：列出我們需要關(guān)注的質(zhì)量屬性點，然后分別從這些質(zhì)量屬性的維度去評估每個方案，再綜合挑選適合當時情況的最優(yōu)方案。

常見的方案質(zhì)量屬性點有：性能、可用性、硬件成本、項目投入、復雜度、安全性、可擴展性等。在評估這些質(zhì)量屬性時，需要遵循架構(gòu)設計的原則： “合適原則”和 “簡單原則”，避免貪大求全，基本上某個質(zhì)量屬性能夠滿足一定時期內(nèi)業(yè)務發(fā)展就可以了。

4 測試方案

良好的測試用例設計能有效提高開發(fā)質(zhì)量，技術(shù)方案中不僅需要考慮開發(fā)自測，為了進一步提高研發(fā)質(zhì)量，還需要考慮如何提高測試同學的測試質(zhì)量和效率。技術(shù)方案在測試這塊需要考慮的點包括：影響點，自測用例，測試注意點。

(1) 影響點
影響點可以用清單的形式列出本次開發(fā)影響了哪塊功能，哪些接口，接口url，改動的內(nèi)容是什么。這樣測試同學在設計測試用例時可以做對照參考，減少功能遺漏測試的情況。

(2) 自測用例
自測用例是介紹說明需求自測的用例設計，可以用清單的形式列出，一般包括涉及場景，測試步驟，測試輸入，期望輸出等信息。

(3) 測試注意點
有些隱藏的異常情況處理，邊界條件，特殊處理邏輯，如果沒有特別說明，測試同學測試的時候很容易遺漏這塊，而線上bug往往出現(xiàn)在這一塊。所以可以在方案里面特殊指出這塊，讓測試同學在測試的時候特別注意一下。

5 上線部署

不想需求上線后各種問題，疲于應對，那就有必要在技術(shù)方案階段考慮上線部署的問題，在技術(shù)方案設計中先提前準備好，等到上線階段對著技術(shù)方案寫的注意事項，步驟進行一步步檢查和執(zhí)行，減少上線事項遺漏或者處理出錯的情況。

上線部署部分涉及的點包括環(huán)境準備，系統(tǒng)準備，發(fā)布順序，線上驗證；

(1) 環(huán)境準備
系統(tǒng)依賴環(huán)境的準備包括MySQL、Redis、MQ、ES和Nginx等服務搭建和初始化，機器資源等。

(2) 系統(tǒng)準備
系統(tǒng)準備常見主要如下：

• 依賴的服務配置，數(shù)據(jù)更新，例如數(shù)據(jù)庫表創(chuàng)建，SQL初始化腳本，Nginx配置更新，MQ的topic創(chuàng)建，網(wǎng)絡端口打通，監(jiān)控配置，IP白名單申請，定時任務創(chuàng)建。
• 引用服務項目配置更新，代碼檢查，分支merge。

(3) 發(fā)布順序
發(fā)布部署的服務之前有業(yè)務依賴關(guān)系，被依賴的服務需要先發(fā)布部署，如果有這種依賴關(guān)系，在技術(shù)方案中應當標明。

(4) 線上驗證
線上驗證的部分，需要說明服務部署之后，怎么驗證服務是否正常，需要做哪些檢查驗證項。例如telnet檢查端口是否通，日志是否有報錯，通過線上測試賬號走一筆業(yè)務看看是否正常，監(jiān)控面板要看哪些指標。

在開發(fā)和測試階段，當配置項，腳本，配置出現(xiàn)更新調(diào)整，需要更新保存在技術(shù)方案文檔里面，上線時照著文檔操作，不容易遺漏。

總結(jié)

想成為優(yōu)秀的開發(fā)人員，不能只局限在開發(fā)領域，而是必須要有跨界的意識，包括產(chǎn)品意識，測試意識、項管意識和運維意識：

• 產(chǎn)品意識：理解產(chǎn)品的具體業(yè)務流程是什么，產(chǎn)品為何這樣設計，目前業(yè)務規(guī)劃的發(fā)展方向，主動溝通產(chǎn)品方案中的不合理之處，提供參考解決辦法。
• 測試意識：技術(shù)方案中要考慮測試同學如何測試，提供必要的細節(jié)信息支撐測試，例如數(shù)據(jù)更新存儲流程。開發(fā)提測前對涉及的影響點做必要的自測，主動溝通測試同學的測試方案的不合理或遺漏的點之處，提供參考解決辦法。
• 項管意識：對任務進行合理分解，在開發(fā)、測試、上線流程中，要及時發(fā)現(xiàn)影響整體進度的問題點，主動協(xié)調(diào)解決或者上報反饋，按照計劃主動推進項目保障最終按時按質(zhì)上線。
• 運維意識：對系統(tǒng)的日常運維、容量和系統(tǒng)瓶頸、系統(tǒng)流量增大擴容方案要有一定的認識和解決方案，保障業(yè)務正常使用。

工具推薦

• 思維工具：結(jié)構(gòu)化分析法、5W2H分析法
• 腦圖軟件：Xmind、百度腦圖
• 畫圖軟件：ProcessOn、PPT、PlantUML