阿里妹導讀
本文簡單講述作者對於“怎麼儘可能快地上手一個新業務/專案？”這個問題的個人理解。
一、儘可能全地蒐集專案資料
不論是轉崗還是加入新團隊，直接從事一個全新的專案機會比較罕見（儘管並非不可能）。大多數情況下，我們會接手別人留下的“遺產”。這無外乎幾種情形：
1、前同事離職，你繼承了他的部分工作；
2、或者你加入了一個新的專案組，被分配了特定的任務；
3、又或者領導對你青睞有加，除了原本職責外，還額外交付了一系列任務，附帶了必要的文件。
所以在第一步，我們要去做的就是收集新專案的專案文件。就像學習一箇中間件或者一門技術一樣，文件就是一份說明書，有了說明書我們才能快速的去了解這個系統的概況甚至是細節。文件沉澱是我們在瞭解一個專案/業務的時候，最直接、便捷的方式。這也是為什麼我覺得要把它放在第一位。
通常團隊都會有一個新人空間，存放一些新人要看的基礎資料資訊，比如一些公共的平臺、程式碼庫地址、專案資訊等等。這些可以幫我們瞭解一些專案的概況，一些基礎能力依賴等等，但是這些對於我們來說可能還不太夠。
我們還需要問帶自己的師兄/組長（不同公司稱謂可能不一樣）要一些我們即將要接受的系統的詳細資料。比如說：系統的架構設計、系統的領域劃分、歷史模組開發時候的設計文件 等等。即使不是自己之後可能負責的模組，有時間也要去閱讀相關的文件，因為模組之間可能也會有一些相互依賴或者彼此支撐的關係存在。
不要不好意思開口去要，即使有點內斂的性格，也要“靦腆”的去要資料！因為我們瞭解的背景、相關領域知識越多，以後上手時候遇到的問題就會越少。不然可能後續需求或者什麼來了，你發現什麼模型我們都不清楚，那就會一步一坎。
二、梳理領域資料模型
我們在讀文件的時候，不要只是簡單的看看，有個印象就好，這對於我們接手一個專案是遠遠不夠的。在這裡拋個問題：我們閱讀文件的根本目的是什麼？（這個問題並不好，其實最根本的問題就是文章的標題 怎麼儘可能快速地上手專案/業務？）
其實解決了這個問題，我們後續的工作就是順藤摸瓜了。那我認為的問題的答案是什麼呢？或者說問題的關鍵是什麼？
這個關鍵問題就是 資料模型。
任何系統和業務的運作，不管是面向過程設計也好，面向物件設計也好，領域模型設計也好，其核心都是資料模型的設計。
單個數據模型自身的設計，比如：包含哪些屬性、每個屬性的含義是什麼、這個模型本身代表什麼等；同時也有資料模型之間關係的設計，比如：商品和SKU是1：n的關係，榜單和商品、商家等等模型是1：n的關係等。當然這裡只是舉個例子哈，具體問題具體分析。
我們在梳理資料模型的過程中，可以嘗試畫ER圖或者其他圖來把這些關係都表示出來，雖然畫圖的過程在外人眼裡可能看起來會花裡胡哨，但是隻要幫助我們更好的理解和記憶這個模型這個系統，那就是一個不錯的方法。我個人就喜歡邊看文件邊作圖，這樣即使後邊忘記了，會過來翻一下之前的圖例，就可以快速的回憶起來。
瞭解了業務系統內對應的資料模型，我們可以根據文件以及我們自己的理解，給他們劃一下不同的領域，然後就可以找出來不同領域的哪些資料模型進行了互動，這樣我們也就慢慢理解了業務裡不同領域的範圍。再到我們看程式碼的時候，我們對程式碼裡的邏輯關係理解也可以更快更輕鬆。
三、理解專案結構及業務邏輯
在完成上述兩步之後，我感覺我們就可以慢慢開始看程式碼了。因為我們已經理解了對應的資料模型，所以我們完全可以按照資料模型作為切入點，開始看專案。
一個專案，通常都會有不同的專案結構，比如說有的是MVC、有的是DDD，又或者其他。所以我們瞭解一個專案，首先肯定就是它的結構、模組（目錄層級）上的劃分。我們可以知道入口層在哪裡、核心邏輯層在哪裡、資料互動層在哪裡、對外暴露的介面一般都定義在哪裡等等這些專案的基礎資訊。瞭解了這些可以方便我們以後定位不同的程式碼在的位置，方便我們快速定位我們疑問的答案可能會出現在哪個目錄（包）下。
之後我們就可以開始鏈路上的熟悉，參照我們之前搞出來的資料模型，我們可以逐個瞭解資料模型在系統內對應的業務邏輯設計/實現（這些在文件裡或多或少也會提及，我們要對比著看），對於每個模組或者功能的業務流程，我們可以邊看邊作業務流程圖來梳理。作圖可以幫我們理清邏輯，也方便實在有看不懂的地方的時候，請教他人。
當然啦，遇到看不懂的流程也很正常，每個系統都會有很多新手不友好的內容。這時候不要害羞，還是那句話：“即使有點內斂的性格，也要“靦腆”的去要xxx”。我們可以去諮詢負責對應業務的同學（一般根據文件的作者都能定位到），問一下我們的問題，然後記錄下來。如此反覆，瞭解系統的不同業務流程瞭解個七七八八（百分百肯定不可能的，後續還是需要透過實踐來補充剩下的知識的）。
四、學習常用平臺相關知識
在瞭解了差不多之後，我們就要開始為我們實戰做準備了。
實戰部分，通常會涉及到：需求的生命週期、專案的部署、開發模式（多分支開發、單分支開發）、中介軟體平臺的使用、日誌查詢等等。
這些一般在新人文件中也應該會有，如果沒有的話，就找自己的師兄問下（能找到肯定還是自己盡力找哈）。自己可以嘗試搞個測試的分支，寫一些測試的程式碼瞭解下中介軟體的使用、平臺的使用等等，走個流程熟悉一下。
到這裡，我感覺我們上手一個專案的準備基本上就差不多了，剩下的一些可能就要在實際專案需求中去學習了。
五、寄語與展望
本文呢，就是簡單講講自己對於“怎麼儘可能快地上手一個新業務/專案？”這個問題的理解，因為是從個人角度的理解寫的，所以可能也會有一些遺漏或者和各位意見不一致的地方，大家有補充的或者指正的，歡迎評論~
希望這些建議能幫助我們快速適應新專案，實現個人和職業的成長！祝願大家 bug–; money++;
MSE實現全鏈路灰度
MSE微服務治理為多應用釋出提供全鏈路灰度能力，讓客戶不修改業務程式碼的情況下實現全鏈路流量控制。
點選閱讀原文檢視詳情。