一、背景

工作中，有一些需求或者技術(shù)改造，老板總是會要我寫出一個技術(shù)方案先和他對一對，作為程序員，我相信大家工作中也經(jīng)常要出技術(shù)方案，技術(shù)方案有沒有一些套路呢，根據(jù)多年來的經(jīng)驗，其實是有的，本文就把平時寫技術(shù)方案的套路總結(jié)出來，有需要的同學可以花幾分鐘時間看下。

二、技術(shù)方案重要性

開發(fā)人員寫代碼前，系統(tǒng)設(shè)計是不可少的，特別是涉及到新功能或者比較大的系統(tǒng)變更，一般都需要技術(shù)方案，技術(shù)方案是整個項目相關(guān)人員都需要了解的，比如系統(tǒng)關(guān)聯(lián)方，前端，,產(chǎn)品和其他維護人員，有時候我們的老板也希望能看到我們的技術(shù)方案，通過技術(shù)方案，更好體現(xiàn)工作量和系統(tǒng)涉及到風險點，還能給項目相關(guān)方都看看方案是否合理。還有我們做開發(fā)久了會發(fā)現(xiàn)，如果一個功能想清楚怎么做了再去落地寫代碼，寫代碼的效率會更高。

本文將結(jié)合作者多年工作實際經(jīng)驗和具體案例，對技術(shù)方案怎么寫來做一次總結(jié)，如果你不知道怎么寫技術(shù)方案，可以先收藏起來備用。大家可以在評論區(qū)分享如何寫一份比較好的技術(shù)方案。

三、常見的技術(shù)方案有哪些內(nèi)容

1、系統(tǒng)用例

這部分能最簡單的反映系統(tǒng)的使用者和系統(tǒng)功能的交互，是系統(tǒng)功能的藍圖。

一般會涉及到用戶端和管理端的用例，可以通過用例圖反映，比如退款申請功能用例：

2、功能整體鏈路

這部分是將用例以及各個系統(tǒng)串連起來，有序的完成整個功能的交互，我們可以通過時序圖來表示。

通過這部分，可以反映功能涉及到的上下游系統(tǒng)，可以明確到相關(guān)接口層面，或者消息等，能體現(xiàn)相關(guān)方的工作量和風險點。比如下方用戶申請退款的時序圖簡圖，作為交易服務(wù)，需要依賴支付服務(wù)。

3、核心業(yè)務(wù)流程

這部分相對于第1部分是更細節(jié)更詳細的設(shè)計，是關(guān)于業(yè)務(wù)功能里比較核心的業(yè)務(wù)邏輯，是一個大功能里對業(yè)務(wù)起關(guān)鍵作用的流程，比如發(fā)起退款里面，對退款的狀態(tài)變更是比較關(guān)鍵的流程，我們一般要把這種核心功能的流程體現(xiàn)出來，可以用時序圖或者流程圖，流程圖表示可以更直觀，對于有一些數(shù)據(jù)或者狀態(tài)變更的操作可以給一些推演案例，這點一般測試人員會比較關(guān)注。

下面是退款流水表退款狀態(tài)的推演記錄：

3、數(shù)據(jù)庫設(shè)計

這塊內(nèi)容是對數(shù)據(jù)庫變更的體現(xiàn)，數(shù)據(jù)庫是我們業(yè)務(wù)系統(tǒng)的最底層，數(shù)據(jù)庫變更應(yīng)該是需要重視的。我們需要考慮數(shù)據(jù)庫設(shè)計的合理性。

是否有新表引入，以及是否有必要性，需要注意新表是否需要分片,考慮數(shù)據(jù)量增量大小，是否需要定期歸檔

舊表新字段引入，需要關(guān)注新字段是否引入慢查詢，是否有大字段，是否有敏感字段，是否需要加索引等，有比較多的情況新功能導(dǎo)致慢sql。

我們可以把ddl語句在文檔中體現(xiàn)出來，突出是新增還是更新。

退款流水記錄表order_refund_record(新增)

CREATE TABLE 'order_refund_record`(
`id`bigint(50) unsigned NOT NULL AUTO INCREMENT COMMENT 'id', order id` varchar (50) NOT NULL COMMENT'訂單id',
`refund_status` int(4) NOT NULL COMMENT'退款狀態(tài)0初始化，1退款中，2退款成功，3退款失敗'，
'create_time' datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT'創(chuàng)建時間'，
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT'更新時間'
`is_delete` tinyint(3) unsigned NOT NULL DEFAULT 'O' COMMENT'是否已刪除0-未刪除1-已刪除' 
PRIMARY KEY (`id`),
) ENGINE = InnoDB DEFAULT CHARSET =utf8mb4 COMMENT-'退款流水記錄表';

4、接口設(shè)計

這部分是比較細節(jié)的設(shè)計了，一般是用于提供給前端或者上下游系統(tǒng)，通過接口設(shè)計可以讓相關(guān)方了解滿足需求。

這部分有rpc接口或者http接口，也可能是消息，需要把傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)定義明確出來，特別是業(yè)務(wù)關(guān)鍵字段，讓相關(guān)方能夠評估改動點，可以知道新接口或者新字段是否可以滿足需求。工作中常用的接口文檔有yapi和swagger。

除了定義接口數(shù)據(jù)格式，接口設(shè)計需要考慮性能，比如，是否需要限流。

5、非功能設(shè)計

5.1、性能與穩(wěn)定性

非功能設(shè)計里面性能和穩(wěn)定性應(yīng)該是需要比較看重的，我們做的功能最基礎(chǔ)的要保障穩(wěn)定可用。

比如新功能如果有新增配置表，我們可以考慮配置表是否放緩存，避免直接查詢數(shù)據(jù)庫，特別是配置表查詢qps比較高的情況。

比如依賴多個下游服務(wù)，下游服務(wù)之間互不依賴，我們可以考慮使用多線程異步并行處理，提高接口吞吐量。

5.2、監(jiān)控

這部分也是很重要的，我們做的功能上線后怎么知道有沒正常運行呢？我們除了看數(shù)據(jù)庫，查日志，比較好的方式就是系統(tǒng)自己有業(yè)務(wù)監(jiān)控，業(yè)務(wù)打點，通過業(yè)務(wù)監(jiān)控可以實時查看業(yè)務(wù)的實際情況。

比如抽獎活動發(fā)獎勵的業(yè)務(wù)功能，我們可以把參與抽獎活動成功，失敗，發(fā)放各類獎勵的數(shù)據(jù)記錄到監(jiān)控平臺，監(jiān)控平臺可視化展示業(yè)務(wù)監(jiān)控。

5.3、核對

這是對于一些核心業(yè)務(wù)功能必須要做的事情，通過核對對賬可以確定我們做的功能有沒有漏洞，避免公司損失。

核對一般有實時核對和離線核對，比如營銷活動發(fā)優(yōu)惠券獎勵，我們需要核對營銷活動發(fā)放規(guī)則和發(fā)放優(yōu)惠券是否正確，避免出現(xiàn)超發(fā)，漏發(fā)，錯發(fā)的情況。

6、系統(tǒng)風險點評估

這部分我們要思考新功能對系統(tǒng)有哪些風險，比如新功能引入對現(xiàn)有功能的影響點風險點，比如功能流量大對系統(tǒng)穩(wěn)定性是否有沖擊，再比如對依賴服務(wù)是否有影響?？赡苓€需要考慮如下點：

• 數(shù)據(jù)庫是否需要擴容
• 緩存是否需要擴容
• 新功能是否需要壓測
• 新接口是否需要限流

四、總結(jié)

技術(shù)方案應(yīng)該是相關(guān)方共同參與并且需要達成共識，技術(shù)方案需要考慮現(xiàn)有的資源成本，現(xiàn)有系統(tǒng)影響，以及合理性多方位來分析，通過技術(shù)文檔可以讓相關(guān)方理解整個功能的業(yè)務(wù)流轉(zhuǎn)邏輯，對于后續(xù)工作推進也有一定作用。

到此這篇關(guān)于七步技術(shù)方案編寫技巧分享的文章就介紹到這了,更多相關(guān)技術(shù)方案技巧內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論