來阿里學到的第一件事竟然是
上一篇offer 總結(jié)文之后有很多玩家后臺給我留言在阿里怎么樣？996嗎？這篇文章主要講來阿里做的很重要的一件事，主要還是圍繞技術(shù)側(cè)給大家做一些輸出。
開場
晚上和供應商溝通完商業(yè)合同的細節(jié)(先賣個關(guān)子)，已經(jīng)12點了，然后開始刷公眾號，刷了一會餓了，床頭放了一罐老婆剛買的牛肉干，糾結(jié)掙扎了3秒，妥協(xié)了（主要是懶得再刷牙），開吃，邊吃邊刷搞笑段子，一不小心沒收住，半罐子沒了。這牛肉干后勁太大，直接辣到肚子疼，肚子疼怎么辦？覺是沒法睡了，那就寫篇文章吧！
給你們看一眼我的牛肉干，可能廚師家辣椒籽不要錢，隨便撒。
臘牛肉
節(jié)奏
交代這個寫作背景，是為了讓你們不要對這篇文章的質(zhì)量有要求或者期待，安琪拉是頂著疼痛的肚子在做輸出，身殘志堅，不來個三連(轉(zhuǎn)發(fā)評論在看)良心不會痛嗎。好了，不賣慘了，下面開始說正事。
1.學到的第一件事
不賣關(guān)子，在阿里學到的第一件事就是”寫文檔“。
你可能會問，在之前難道不寫文檔嗎？寫，但是阿里寫的更細致、更具體，文檔是工程非常核心的一部分，寫文檔時間甚至多余寫代碼時間，因為其中涉及很多思考沉淀，畫流程圖、交互圖，還有修改完善。文檔是整個研發(fā)流程中非常關(guān)鍵的一個步驟，螞蟻大體的研發(fā)流程是：
提需求 -> 需求評審 -> 研發(fā)做系分 -> 系分評審 -> 編碼 -> ?MR -> 代碼效能檢測 -> CR -> ….
安琪拉今天主要說的文檔是螞蟻非常重視的系分文檔，系分是“系統(tǒng)分析與設計” 的簡稱。在螞蟻的研發(fā)體系培訓中專門有一門“系分”課程，是魯肅來教的，可見螞蟻對系分的重視。這么說吧，做的好的系分的標準就是讓另一個開發(fā)拿到你的系分文檔，可以直接依據(jù)系分文檔完成編碼。
系分評審會議上大家會直接拋出很多問題，你需要對系分設計的每一個細節(jié)考慮清楚，比如交互邏輯、技術(shù)風險等，安琪拉的系分在評審會議上第一次沒有通過，后面好幾晚都弄到凌晨2點，二個周末在高鐵上、餐桌上都在做系分。第二次評審非常順利，還得到了Leader 的贊揚。另外為什么強調(diào)是技改，因為技改和新需求不太一樣，新需求的系分主要為了滿足業(yè)務新需求，技改系分設計主要對現(xiàn)有實現(xiàn)做方案調(diào)整優(yōu)化。
你們可能會懷疑，不就是一個文檔嘛，至于又是熬夜、又是犧牲周末時間來弄嘛。我就仔細說說技改的系分文檔都包含哪些內(nèi)容，個人覺得對開發(fā)想要往架構(gòu)師方向發(fā)展是有借鑒意義的，即使不往架構(gòu)走，把自己業(yè)務和技術(shù)細節(jié)梳理清楚也大有裨益。
做系分文檔有什么好處呢？安琪拉認為最大的好處是：通過系統(tǒng)分析設計文檔可以降低編碼的不確定性，系分做的越詳細，編碼時不確定性就越小，因為所有問題、邊界、流程、數(shù)據(jù)處理你都提前想清楚了，文檔就是一種把腦海中的設計思路具體化的方式，另外一方面就是通過系分評審，讓小組內(nèi)成員幫你把關(guān)，可能你考慮有遺漏的地方，大家一起評審就容易發(fā)現(xiàn)問題，最后一個好處就是可維護性，不管是新人還是后續(xù)接手項目的人，不用你一點一點口口相傳教他，看你的文檔一目了然，另外是人就會遺忘，戰(zhàn)勝遺忘最好的方式就是記錄。
下面以安琪拉在國服群里討論的黑名單需求說明系分設計是怎么做的，不會太細，但是整體框架思路相信基本可以借鑒。大家甚至可以依此作為技改需求開發(fā)規(guī)范的模板。
需求背景
舉一個案例，是關(guān)于黑名單治理的，商家發(fā)布的商品信息可能需要放置到黑名單池子中，主要就是防止一些黑灰產(chǎn)、敏感詞、惡意導流等，還有一些場景，相信做技術(shù)的同學應用里面多多少少都有這種類型的黑、白名單的功能。
系分內(nèi)容
大綱
修訂歷史
概述
業(yè)務流程
現(xiàn)有系統(tǒng)設計與問題
技改方案
非功能性需求
保障性方案
工作量評估與排期
關(guān)鍵節(jié)點與問題跟進
附錄
參考文檔
看大綱覺得是沒什么，鑒于信息保密的原因，不能把完整的目錄細節(jié)截圖放出來，大家做過畢業(yè)答辯的系統(tǒng)設計文檔應該知道有多詳細，這份技改的系分文檔差不多就是這個程度?？创缶V沒覺得東西多，遇到影響面大的技改，第3點的內(nèi)容就夠喝一壺的。
下面具體介紹每一部分：
0.修訂歷史
把每一版本的文檔修改點和時間列出來，好追溯，目前這份需求已經(jīng)到第四個版本
1.概述
這部分主要是交代需求背景，為什么要做這件事，要達到什么業(yè)務目標和技術(shù)目標？目標要清晰、可量化，不能模棱二可。
2.業(yè)務流程
這部分會畫一些用例圖，業(yè)務場景描述，核心業(yè)務流程等。
3.現(xiàn)有系統(tǒng)設計與問題
上一部分描述完業(yè)務的場景和流程，這一趴就講現(xiàn)在系統(tǒng)是如何滿足和實現(xiàn)這些業(yè)務需求的，實現(xiàn)的有什么問題。這部分需要描述：
3.1 現(xiàn)在用的技術(shù)方案，例如：使用的領(lǐng)域模型、關(guān)鍵技術(shù)棧(用到的中間件、緩存等)、數(shù)據(jù)流、模塊的交互邏輯等。
3.2 現(xiàn)在技術(shù)方案的問題，例如：數(shù)據(jù)一致性問題、模塊實現(xiàn)的時間復雜度高、有異常、不滿足業(yè)務擴展性等等問題。
3.3 問題的影響范圍和引用點，例如：有業(yè)務交互的外部系統(tǒng)、內(nèi)部模塊，引用點的調(diào)用量，區(qū)分影響點哪些是關(guān)鍵業(yè)務。這一塊在安琪拉這次技改中花了最多時間，因為黑名單幾乎所有關(guān)鍵業(yè)務鏈路都用到了，需要梳理清楚影響的范圍和實現(xiàn)的邏輯，我是按照TPS 從高到低排列這些引用點(為了切新流程的時候優(yōu)先切流量低的引用點驗證新技術(shù)實現(xiàn)的正確性)，把實現(xiàn)的邏輯歸類，交互時序圖畫出來。下面截了一張系分的問題匯總的圖：
外部系統(tǒng)影響范圍花了個示例圖：
可以列出關(guān)鍵鏈路。
4.技改方案
上一部分提到的問題，在這一趴需要有對應的方案解決。包括：新的領(lǐng)域模型設計、擴展性更好的接口設計、新方案的技術(shù)分層，如下給了一張示意圖，隱去了部分敏感信息，這個是我找的一個老版本的，新版本core-service模塊再擴展出來一層。
對于關(guān)鍵業(yè)務鏈路的交互實現(xiàn)，也需要把技改方案和歷史方案作對比，尤其是新方案的風險，這個是很重要的，一般在穩(wěn)定性方面都要求做開關(guān)配置，在新方案試運行期間，可以通過開關(guān)切到舊方案中。
關(guān)鍵鏈路需要把方案的數(shù)據(jù)流程也表達出來，如果有資金方面的交互也要表達出來。下圖是一個關(guān)鍵鏈路的交互圖：
5.非功能性需求
就是非功能方面的需求，字面意思
6.保障性方案
新功能上線，螞蟻是強制要求做到三點：可灰度、可監(jiān)控、可回滾，灰度是用少部分流量驗證功能正確性，監(jiān)控是隨時隨地明確知道系統(tǒng)運行監(jiān)控狀況，可回滾不用說，有問題時不能回不去。
7.工作量評估與排期
這個需要定開發(fā)、提測、代碼review、走讀和評審、測試、聯(lián)調(diào)、上線的時間
8.關(guān)鍵節(jié)點與問題跟進
關(guān)鍵節(jié)點記錄，遺留問題記錄和跟進，相當于備忘錄
9.附錄
不適合在主要系分設計中列出的附加說明
10.參考文檔
文章依賴的一些例如中間件、技術(shù)棧出處，讓系分文檔評審的人，以及后面接手維護的人知道技術(shù)方案的來源。
2. 首尾呼應
文章開頭那個商務合同是昨晚在和旅行社定團隊outing 合同的細節(jié)，馬上要去和小伙伴們一起去爬山了，有一起的嗎？你們說安琪拉要不要把老板拉到一邊，問他：”今年的晉升，你看我還有機會嗎？“
覺得時間真的太少，要弄得東西太多了，本來昨天晚上就想把這篇文章寫好，實在太困，今天還在機場候車廳碼字，下面放了機場碼字圖，渣技術(shù)，馬上要去西安了，大家有什么推薦的吃的嗎，雖然就半天時間，還是想盡快多吃點西安美食。
—?【 THE END 】— 本公眾號全部博文已整理成一個目錄，請在公眾號里回復「m」獲取！ 3T技術(shù)資源大放送！包括但不限于：Java、C/C++，Linux，Python，大數(shù)據(jù)，人工智能等等。在公眾號內(nèi)回復「1024」，即可免費獲取??！