掃二維碼與項目經(jīng)理溝通
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
我們?yōu)槭裁葱枰獙懠夹g(shù)方案?總結(jié)下來無非是幾點，從不同人的視角來看：
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了裕民免費建站歡迎大家使用！
我們都知道技術(shù)方案是指導(dǎo)具體開發(fā)工作的，可以分別從開發(fā)的事前、事中、事后來討論這個問題。
一篇好的技術(shù)方案可以貫穿整個研發(fā)的生命周期，并且能起到很好的指導(dǎo)意義，就如同寫小說之前作者必須出一個大綱的邏輯是一致的。
那么，如何寫出一篇好的技術(shù)方案呢?下面列舉出筆者認為應(yīng)該做到的一些點。
一份技術(shù)文檔需要有一個清晰的目標(業(yè)務(wù)需求建議自己總結(jié)而不是 Copy from
PRD，技術(shù)自發(fā)的那肯定得自己總結(jié))，那目標怎么來的呢?是從需求里轉(zhuǎn)化過來的。那么，如何將對應(yīng)的需求轉(zhuǎn)化為一個清晰的目標?我認為最重要的是要盡量定義一個可衡量的標準。需求的種類一般來說就兩種，分別是：1.
1.產(chǎn)品類需求——業(yè)務(wù)方 or 產(chǎn)品方發(fā)起提給技術(shù)，包括但不限于以下幾種：
2. 技術(shù)類需求——技術(shù)自發(fā)提出，包括但不限于以下幾種：
在眾多的需求當中還有一些是我們要去辨別的偽需求——不是用戶真正想要的需求，如用戶想要將一個飛機改造成火箭，但是產(chǎn)品可能提過來的僅僅是把飛機的兩個翅膀砍掉，那么砍掉翅膀就能變成火箭了嗎?明顯不能，所以這種需求一定要注意鑒別。
有句話叫“不謀全局者不足謀一域”，在技術(shù)方案中我想也是如此。在一個技術(shù)方案中，一個大綱圖是不可或缺的
，有的人叫它技術(shù)架構(gòu)圖，有的人叫它數(shù)據(jù)流轉(zhuǎn)圖，這都不重要，重要的是我們能從這張圖中看到整體的脈絡(luò)，那么這張圖需要有哪幾個要點呢?
大綱圖的邏輯示意參考
講到數(shù)據(jù)模型設(shè)計，E-R 圖是必不可少的，E-R 圖應(yīng)該包含以下信息：
技術(shù)方案 1：需要依賴緩存、分布式調(diào)度中間件、消費外部的消息，但是沒有把對應(yīng)的中間件使用方式、數(shù)據(jù)格式貼出來。
技術(shù)方案 2：需要依賴緩存、分布式調(diào)度中間件、消費外部的消息，將緩存接入的方法 & 對應(yīng)的緩存 key-value
設(shè)計寫清楚，將分布式調(diào)度中間件接入所需要準備的依賴項梳理好，將外銷消息對應(yīng)的 topic 和數(shù)據(jù)格式列清楚。
兩個方案對比好壞其實很明顯。如果一開始我們在技術(shù)方案里面將外部依賴確定好，那么我們在開發(fā)的時候就一馬平川，反之如果外部依賴都不確定的情況下就進入到開發(fā)，那么返工的概率將大大增加，從而降低我們的工作效率。
那么，對外的依賴有哪些以及我們應(yīng)該要確認什么信息呢?下面列舉了一些常見的依賴情況：
模塊依賴層次從高到低分為：
我們舉接口依賴的例子來看：一共三個接口分別是滾存看板查詢接口、鎖接口、渠道集接口，滾存看板查詢接口依賴于鎖接口和渠道集接口。
技術(shù)方案 1 目錄層次：滾存看板查詢接口、鎖接口、渠道集接口;
技術(shù)方案 2 目錄層次：鎖接口、渠道集接口、滾存看板查詢接口。
很明顯，技術(shù)方案 2 是更加合理的，A 依賴于 B 那么 B 應(yīng)該先做。我們在寫技術(shù)方案的時候，要考慮什么應(yīng)該在前什么應(yīng)該在后，而不是想一步寫一步。要有一個清晰、有序的結(jié)構(gòu)，不然別人看起來就會是雜亂無章的。
下面列出一個技術(shù)方案的模塊里面應(yīng)該要寫哪些東西，供參考：
要求：實現(xiàn)一個飛機運力合同查詢接口，入?yún)檫\力大區(qū)
技術(shù)方案 1：
入?yún)ⅲ?br>{
"area": "南美"
}
出參:
{
"date": "***"
}技術(shù)方案 2：
方法名：CapacityService.queryPlan
入?yún)ⅲ?br>{
"cnArea": "南美"
}
出參:
{
"date": "***"
}
技術(shù)方案 2 是更好的，為什么?測試、前端 、后續(xù)要接手該接口的人都能夠一下子找到你的接口并清楚知道輸入輸出是什么。另外，1 和 2 的入?yún)⒁粋€ area 一個 cnArea，那么到底哪個更對呢?這里由于系統(tǒng)中在用的都是 cnArea，固沿用 cnArea 是對的(一致性減小溝通成本)。
這里總結(jié)對接口定義有幾點要求：
要求：實現(xiàn)一個學生信息查詢接口。
技術(shù)方案 1：寫出查詢結(jié)果中執(zhí)行的相關(guān)步驟。
step1. 入?yún)⑿ｒ?br>step2. 查詢A表
step3. 對A標返回結(jié)果做校驗
step4. 查詢B表
······
技術(shù)方案 2：在 1 的基礎(chǔ)上使用時序圖表達出來。
推薦使用技術(shù)方案 2，好處是盡管內(nèi)容相同但是時序圖能夠更直觀地看到層次、數(shù)據(jù)流轉(zhuǎn)等信息。
除了以上比較基礎(chǔ)的 2 點，我覺得的還有一些要點：
要求：實現(xiàn)一個定時任務(wù)，定期將過期的數(shù)據(jù)刪除。
技術(shù)方案 1：使用 spring 自帶的定時器進行數(shù)據(jù)清除。
技術(shù)方案 2：使用分布式調(diào)度中間件(如 schedulerx)進行定時過期數(shù)據(jù)清除。
乍一看好像都能實現(xiàn)，但仔細對比兩個實現(xiàn)方式之后我認為大部分人還是會選擇技術(shù)方案 2，為什么?下面列出一些在選擇技術(shù)方案時考慮的點。
|
目標是否可達成 |
實現(xiàn)難度 |
可維護性 |
可擴展性 | |
|
技術(shù)方案1-spring定時器 |
是 |
易 |
易 |
低 |
|
技術(shù)方案2-分布式調(diào)度中間件 |
是 |
易 |
中 |
高 |
安全生產(chǎn)包括幾個部分，包括且不限于下面幾個部分：
我們舉一個例子。
需求：在消費者收貨成功時觸發(fā)對商家的結(jié)算。
技術(shù)方案 1：******，寫了一堆如何觸發(fā)結(jié)算、如何更好地支持后續(xù)的可擴展性;
技術(shù)方案 2：******，寫的方案可擴展性沒有技術(shù)方案 1 高，但是做好了未觸發(fā)結(jié)算的監(jiān)控、觸發(fā)結(jié)算之后的對賬，并設(shè)計好了對應(yīng)的報表防止出現(xiàn)資損。
其實這也是我們在技術(shù)方案中可能會忽略的一點——埋頭于代碼結(jié)構(gòu)如何如何的好，但是有些東西其實是要比單純的代碼更重要。就比如風險控制，完備的監(jiān)控、不可缺少的對賬是保障公司資金安全，更是保障我們自己績效的工具(此處應(yīng)有表情)。
那么對于監(jiān)控、對賬的具體要求是什么呢?我認為有以下幾點：
還有其它幾個部分也補充說一下：灰度方案，包括但不限于：
向前兼容性，包括但不限于：
發(fā)布流程，包括但不限于：
我們在微信上24小時期待你的聲音
解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動版官網(wǎng)