建站
咨詢
售后
建站咨詢
新聞中心
我們?yōu)槭裁葱枰獙懠夹g(shù)方案?總結(jié)下來(lái)無(wú)非是幾點(diǎn)，從不同人的視角來(lái)看：
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了裕民免費(fèi)建站歡迎大家使用！
- 產(chǎn)品：驗(yàn)證技術(shù)方案是否能夠 match 上產(chǎn)品方案
- 測(cè)試：驗(yàn)證技術(shù)方案對(duì)測(cè)試方案是否有足夠 & 準(zhǔn)確的輸入
- 同事 & leader：參與技術(shù)方案評(píng)審，驗(yàn)證技術(shù)方案的合理性
- 新人(不單單指新同學(xué)也指新接觸這一塊的同學(xué))：拿到技術(shù)方案可以很快對(duì)某一塊的事情熟悉起來(lái)
什么樣的技術(shù)方案是一個(gè)好的技術(shù)方案
我們都知道技術(shù)方案是指導(dǎo)具體開(kāi)發(fā)工作的，可以分別從開(kāi)發(fā)的事前、事中、事后來(lái)討論這個(gè)問(wèn)題。
事前
- 明確的目標(biāo)：整個(gè)技術(shù)方案要達(dá)成什么目的
- 低溝通成本：產(chǎn)品測(cè)試能從技術(shù)方案上獲取足夠的輸入，不需要反復(fù)找你確認(rèn)
- 技術(shù)選型思考：為什么要這么做?和業(yè)內(nèi)方案相比有什么好處和壞處，如何權(quán)衡的
事中
- 少調(diào)整：盡可能少的技術(shù)方案需要調(diào)整， 否則無(wú)法完成開(kāi)發(fā)任務(wù)
事后
- 少補(bǔ)?。罕M可能少的 bug 或者遺漏
- 可擴(kuò)展 & 可復(fù)用：相對(duì)簡(jiǎn)單的改動(dòng)就能支持新增需求，類似場(chǎng)景可復(fù)用不需要重復(fù)開(kāi)發(fā)
一篇好的技術(shù)方案可以貫穿整個(gè)研發(fā)的生命周期，并且能起到很好的指導(dǎo)意義，就如同寫小說(shuō)之前作者必須出一個(gè)大綱的邏輯是一致的。
如何寫好一篇好的技術(shù)方案
那么，如何寫出一篇好的技術(shù)方案呢?下面列舉出筆者認(rèn)為應(yīng)該做到的一些點(diǎn)。
清晰的目標(biāo)
一份技術(shù)文檔需要有一個(gè)清晰的目標(biāo)(業(yè)務(wù)需求建議自己總結(jié)而不是 Copy from
PRD，技術(shù)自發(fā)的那肯定得自己總結(jié))，那目標(biāo)怎么來(lái)的呢?是從需求里轉(zhuǎn)化過(guò)來(lái)的。那么，如何將對(duì)應(yīng)的需求轉(zhuǎn)化為一個(gè)清晰的目標(biāo)?我認(rèn)為最重要的是要盡量定義一個(gè)可衡量的標(biāo)準(zhǔn)。需求的種類一般來(lái)說(shuō)就兩種，分別是：1.
1.產(chǎn)品類需求——業(yè)務(wù)方 or 產(chǎn)品方發(fā)起提給技術(shù)，包括但不限于以下幾種：
- 頁(yè)面交互：能提升多少的運(yùn)營(yíng)操作效率，多少 PV、UV 這種可量化的數(shù)字?
- 業(yè)務(wù) SOP 調(diào)整：帶來(lái)的業(yè)務(wù)價(jià)值是什么?是能降多少本還是提升多少時(shí)效?
- 數(shù)據(jù)訂正：訂正能解決什么問(wèn)題?防止多少錢未結(jié)算?又或者是防止多少客訴?
2. 技術(shù)類需求——技術(shù)自發(fā)提出，包括但不限于以下幾種：
- 性能優(yōu)化：優(yōu)化多少?20%、30% 還是 50%?
- 數(shù)據(jù)隔離：隔離的范圍是什么，涉及多少?gòu)埍?，多少?shù)據(jù)?可以減少當(dāng)前的什么問(wèn)題?減少多少?
- 各種小工具：沒(méi)有小工具之前是什么樣?有之后是什么樣?可以帶來(lái)什么好處?
- 研發(fā)效能提升：提升多少?有沒(méi)有可以量化的指標(biāo)?而不是為了做而做。
在眾多的需求當(dāng)中還有一些是我們要去辨別的偽需求——不是用戶真正想要的需求，如用戶想要將一個(gè)飛機(jī)改造成火箭，但是產(chǎn)品可能提過(guò)來(lái)的僅僅是把飛機(jī)的兩個(gè)翅膀砍掉，那么砍掉翅膀就能變成火箭了嗎?明顯不能，所以這種需求一定要注意鑒別。
大綱圖
有句話叫“不謀全局者不足謀一域”，在技術(shù)方案中我想也是如此。在一個(gè)技術(shù)方案中，一個(gè)大綱圖是不可或缺的
，有的人叫它技術(shù)架構(gòu)圖，有的人叫它數(shù)據(jù)流轉(zhuǎn)圖，這都不重要，重要的是我們能從這張圖中看到整體的脈絡(luò)，那么這張圖需要有哪幾個(gè)要點(diǎn)呢?
- 圖不用很細(xì)(比如加工比較復(fù)雜我們可以簡(jiǎn)單寫**加工)，但是要能看到全貌，具體的每個(gè)模塊如果需要展開(kāi)的，那么在對(duì)應(yīng)的詳細(xì)設(shè)計(jì)中體現(xiàn)即可，在這里我們關(guān)注的是整體;
- 接口如有歸屬不同的應(yīng)用要標(biāo)明;
- 數(shù)據(jù)存儲(chǔ)介質(zhì)不同要標(biāo)明;
- 數(shù)據(jù)流轉(zhuǎn)的箭頭要清晰明確;
- 數(shù)據(jù)加工計(jì)算的輸入和輸出要體現(xiàn)，同時(shí)要體現(xiàn)加工的運(yùn)行環(huán)境(比如到底是 odps 計(jì)算還是內(nèi)存計(jì)算，內(nèi)存計(jì)算的話是在那個(gè)應(yīng)用)。
大綱圖的邏輯示意參考
模型設(shè)計(jì)
講到數(shù)據(jù)模型設(shè)計(jì)，E-R 圖是必不可少的，E-R 圖應(yīng)該包含以下信息：
- 每個(gè)領(lǐng)域?qū)ο螅绻志没?，都有表?lái)存儲(chǔ)。我們?cè)O(shè)計(jì)完 ER 圖的時(shí)候，應(yīng)該根據(jù)這條原則做一番檢查，避免漏掉一些表。在大型項(xiàng)目中，漏掉表是很常見(jiàn)的事情，應(yīng)盡量避免。
- 領(lǐng)域?qū)ο笾g的關(guān)系，如果要持久化，都要在表結(jié)構(gòu)中體現(xiàn)。這種體現(xiàn)，可能是 code 字段，可能是外鍵，可能是中間表。我們?cè)O(shè)計(jì)完 ER 圖的時(shí)候，也應(yīng)該根據(jù)這條原則做一番檢查，避免漏掉一些關(guān)系。在大型項(xiàng)目中，漏掉關(guān)系更是司空見(jiàn)慣，應(yīng)盡量避免。
- 清晰定義的表名。設(shè)計(jì) ER 圖的時(shí)候，就要設(shè)計(jì)出清晰定義的表名。清晰定義的表名，可以幫助大家理解 ER 圖，可以幫助大家映射回領(lǐng)域?qū)ο蠹捌潢P(guān)系。在后續(xù)的設(shè)計(jì)和實(shí)施中，將沿用這個(gè)表名。
- 清晰定義的字段名、字段類型、字段長(zhǎng)度和枚舉值。很多同學(xué)容易忽略這點(diǎn)，他們往往清晰定義了表名，卻沒(méi)有重視表的字段。認(rèn)真去做的時(shí)候，會(huì)發(fā)現(xiàn)，這里面有很多工作。例如，字段名是否合適，用什么類型好，字段長(zhǎng)度多少合適，是否有枚舉值等等，都需要一一斟酌。如果這點(diǎn)做好了，在實(shí)施的時(shí)候，可以避免很多麻煩，甚至避免返工。
對(duì)外依賴提前確認(rèn)
技術(shù)方案 1：需要依賴緩存、分布式調(diào)度中間件、消費(fèi)外部的消息，但是沒(méi)有把對(duì)應(yīng)的中間件使用方式、數(shù)據(jù)格式貼出來(lái)。
技術(shù)方案 2：需要依賴緩存、分布式調(diào)度中間件、消費(fèi)外部的消息，將緩存接入的方法 & 對(duì)應(yīng)的緩存 key-value
設(shè)計(jì)寫清楚，將分布式調(diào)度中間件接入所需要準(zhǔn)備的依賴項(xiàng)梳理好，將外銷消息對(duì)應(yīng)的 topic 和數(shù)據(jù)格式列清楚。
兩個(gè)方案對(duì)比好壞其實(shí)很明顯。如果一開(kāi)始我們?cè)诩夹g(shù)方案里面將外部依賴確定好，那么我們?cè)陂_(kāi)發(fā)的時(shí)候就一馬平川，反之如果外部依賴都不確定的情況下就進(jìn)入到開(kāi)發(fā)，那么返工的概率將大大增加，從而降低我們的工作效率。
那么，對(duì)外的依賴有哪些以及我們應(yīng)該要確認(rèn)什么信息呢?下面列舉了一些常見(jiàn)的依賴情況：
- 外部 hsf 依賴：需要確認(rèn)對(duì)應(yīng) hsf 接口的類、方法、version，以及二方包(也可使用泛化調(diào)用);
- 外部消息依賴：需要確認(rèn)消息的 topic、數(shù)據(jù)格式;
- 分布式調(diào)度、緩存等中間件：當(dāng)前應(yīng)用是否接入過(guò)該中間件，未接入需要去到官網(wǎng)確認(rèn)接入文檔，接入的話需要確認(rèn)是否可以復(fù)用接入邏輯。
內(nèi)部前后模塊依賴 & 層次結(jié)構(gòu)
模塊依賴層次從高到低分為：
- 領(lǐng)域依賴(如交易依賴商品)；
- 應(yīng)用依賴(如 cntcp 應(yīng)用依賴 cngfc 應(yīng)用)；
- 接口依賴(如滾存看板查詢接口依賴于鎖接口 & 渠道集接口)。
我們舉接口依賴的例子來(lái)看：一共三個(gè)接口分別是滾存看板查詢接口、鎖接口、渠道集接口，滾存看板查詢接口依賴于鎖接口和渠道集接口。
技術(shù)方案 1 目錄層次：滾存看板查詢接口、鎖接口、渠道集接口;
技術(shù)方案 2 目錄層次：鎖接口、渠道集接口、滾存看板查詢接口。
很明顯，技術(shù)方案 2 是更加合理的，A 依賴于 B 那么 B 應(yīng)該先做。我們?cè)趯懠夹g(shù)方案的時(shí)候，要考慮什么應(yīng)該在前什么應(yīng)該在后，而不是想一步寫一步。要有一個(gè)清晰、有序的結(jié)構(gòu)，不然別人看起來(lái)就會(huì)是雜亂無(wú)章的。
一個(gè)模塊里面應(yīng)該有啥
下面列出一個(gè)技術(shù)方案的模塊里面應(yīng)該要寫哪些東西，供參考：
1. 具體的接口定義
要求：實(shí)現(xiàn)一個(gè)飛機(jī)運(yùn)力合同查詢接口，入?yún)檫\(yùn)力大區(qū)
技術(shù)方案 1：
入?yún)ⅲ?br>{
"area": "南美"
}
出參:
{
"date": "***"
}技術(shù)方案 2：
方法名：CapacityService.queryPlan
入?yún)ⅲ?br>{
"cnArea": "南美"
}
出參:
{
"date": "***"
}
技術(shù)方案 2 是更好的，為什么?測(cè)試、前端 、后續(xù)要接手該接口的人都能夠一下子找到你的接口并清楚知道輸入輸出是什么。另外，1 和 2 的入?yún)⒁粋€(gè) area 一個(gè) cnArea，那么到底哪個(gè)更對(duì)呢?這里由于系統(tǒng)中在用的都是 cnArea，固沿用 cnArea 是對(duì)的(一致性減小溝通成本)。
這里總結(jié)對(duì)接口定義有幾點(diǎn)要求：
- 完整的類和方法名；
- 入?yún)⒆侄稳绻到y(tǒng)中已有，那便沿用;如果沒(méi)有，那么英文的描述需要準(zhǔn)確(可同產(chǎn)品業(yè)務(wù)商榷)；
- 出參字段要求同入?yún)ⅰ?/li>
2. 詳細(xì)的時(shí)序圖
要求：實(shí)現(xiàn)一個(gè)學(xué)生信息查詢接口。
技術(shù)方案 1：寫出查詢結(jié)果中執(zhí)行的相關(guān)步驟。
step1. 入?yún)⑿ｒ?yàn)
step2. 查詢A表
step3. 對(duì)A標(biāo)返回結(jié)果做校驗(yàn)
step4. 查詢B表
······
技術(shù)方案 2：在 1 的基礎(chǔ)上使用時(shí)序圖表達(dá)出來(lái)。
推薦使用技術(shù)方案 2，好處是盡管內(nèi)容相同但是時(shí)序圖能夠更直觀地看到層次、數(shù)據(jù)流轉(zhuǎn)等信息。
除了以上比較基礎(chǔ)的 2 點(diǎn)，我覺(jué)得的還有一些要點(diǎn)：
- 數(shù)據(jù)加工的詳細(xì)圖(如有)——同樣推薦用圖的形式可以更直觀；
- 消息設(shè)計(jì)(如有)，明確消息生產(chǎn)方、消費(fèi)方、tps、數(shù)據(jù)結(jié)構(gòu)；
- 自測(cè)用例(推薦)，比較重要的功能點(diǎn)構(gòu)造一些自測(cè)用例。
- ······
技術(shù)選型分析
要求：實(shí)現(xiàn)一個(gè)定時(shí)任務(wù)，定期將過(guò)期的數(shù)據(jù)刪除。
技術(shù)方案 1：使用 spring 自帶的定時(shí)器進(jìn)行數(shù)據(jù)清除。
技術(shù)方案 2：使用分布式調(diào)度中間件(如 schedulerx)進(jìn)行定時(shí)過(guò)期數(shù)據(jù)清除。
乍一看好像都能實(shí)現(xiàn)，但仔細(xì)對(duì)比兩個(gè)實(shí)現(xiàn)方式之后我認(rèn)為大部分人還是會(huì)選擇技術(shù)方案 2，為什么?下面列出一些在選擇技術(shù)方案時(shí)考慮的點(diǎn)。
|
目標(biāo)是否可達(dá)成 |
實(shí)現(xiàn)難度 |
可維護(hù)性 |
可擴(kuò)展性 | |
|
技術(shù)方案1-spring定時(shí)器 |
是 |
易 |
易 |
低 |
|
技術(shù)方案2-分布式調(diào)度中間件 |
是 |
易 |
中 |
高 |
安全生產(chǎn)
安全生產(chǎn)包括幾個(gè)部分，包括且不限于下面幾個(gè)部分：
- 監(jiān)控
- 對(duì)賬
- 灰度方案
- 數(shù)據(jù)隔離
- 兼容性評(píng)估
- 發(fā)布流程
我們舉一個(gè)例子。
需求：在消費(fèi)者收貨成功時(shí)觸發(fā)對(duì)商家的結(jié)算。
技術(shù)方案 1：******，寫了一堆如何觸發(fā)結(jié)算、如何更好地支持后續(xù)的可擴(kuò)展性;
技術(shù)方案 2：******，寫的方案可擴(kuò)展性沒(méi)有技術(shù)方案 1 高，但是做好了未觸發(fā)結(jié)算的監(jiān)控、觸發(fā)結(jié)算之后的對(duì)賬，并設(shè)計(jì)好了對(duì)應(yīng)的報(bào)表防止出現(xiàn)資損。
其實(shí)這也是我們?cè)诩夹g(shù)方案中可能會(huì)忽略的一點(diǎn)——埋頭于代碼結(jié)構(gòu)如何如何的好，但是有些東西其實(shí)是要比單純的代碼更重要。就比如風(fēng)險(xiǎn)控制，完備的監(jiān)控、不可缺少的對(duì)賬是保障公司資金安全，更是保障我們自己績(jī)效的工具(此處應(yīng)有表情)。
那么對(duì)于監(jiān)控、對(duì)賬的具體要求是什么呢?我認(rèn)為有以下幾點(diǎn)：
監(jiān)控：
- 監(jiān)控目標(biāo)：寫清楚監(jiān)控的是什么內(nèi)容；
- 監(jiān)控點(diǎn)：如通過(guò)打印日志監(jiān)控，那么日志打印在哪個(gè)類的哪個(gè)方法；
- 監(jiān)控觸發(fā)：是通過(guò) sunfire 采集觸發(fā)還是其它，如果是 sunfire 采集最好能把監(jiān)控項(xiàng)地址貼出來(lái)；
- 監(jiān)控訂閱人：監(jiān)控告警需要的訂閱人；
- 監(jiān)控觸發(fā)后的解決方法：如果發(fā)生異常該如何解決?如手工觸發(fā)結(jié)算。
對(duì)賬：
- 對(duì)賬目標(biāo)：寫清楚對(duì)賬是為什么；
- 對(duì)賬方式：寫清楚是怎么對(duì)賬的(如通過(guò) odps 天級(jí)定時(shí)任務(wù)，履行單上的關(guān)務(wù)資源 code 和日志表中關(guān)務(wù) cp 回傳報(bào)文的關(guān)務(wù)資源 code 對(duì)比要一致，不一致的形成某個(gè)數(shù)據(jù)集，通過(guò)錦衣衛(wèi)-資損風(fēng)險(xiǎn)平臺(tái)配置)；
- 對(duì)賬告警訂閱人；
- 對(duì)賬異常之后的解決辦法。
還有其它幾個(gè)部分也補(bǔ)充說(shuō)一下：灰度方案，包括但不限于：
- 多方前置準(zhǔn)備；
- 灰度切流開(kāi)關(guān)設(shè)計(jì)；
- 灰度切流節(jié)奏；
- 異常應(yīng)對(duì)。
向前兼容性，包括但不限于：
- 接口的向前兼容：尤其是對(duì)外的接口；
- 數(shù)據(jù)結(jié)構(gòu)的向前兼容：如不能隨意改變字段的存儲(chǔ)類型和格式。
環(huán)境隔離：
- 如有租戶隔離 & 預(yù)發(fā)線上隔離的情況需要考慮數(shù)據(jù)。
發(fā)布流程，包括但不限于：
- 發(fā)布計(jì)劃；
- 檢查項(xiàng)列表；
- 發(fā)布流量監(jiān)控。
網(wǎng)頁(yè)標(biāo)題：如何寫出一篇好的技術(shù)方案？
文章出自：http://m.fisionsoft.com.cn/article/cdgdgeh.html
