我是一個著迷於產品和運營的技術人，樂於跨界的終身學習者。歡迎關注我喲～
每週五早6點 按時送達～
我的第「207」篇原創敬上
大家好，我是 Z 哥。
所謂“跳槽爽，一直跳槽一直爽”。但是，世上哪有那麼好的事哦，跳槽雖然可以帶來更快的漲薪機會，但是你也是要面對和克服一些新挑戰的，其中最大的挑戰莫過於要熟悉一個陌生的專案。畢竟，進入到一個新的團隊，又恰好遇到做的是一個新專案，這個機率就太小了。
對我們程式設計師來說，這裡的陌生專案就是一套陌生的原始碼。
有時候如果運氣好，有一位帶教老師或者熱心的同事來幫助你熟悉專案，那自然會輕鬆很多，速度也更快。
但是如果你運氣沒那麼好，或者去到了一個人員緊張的快速發展期企業，那就只能靠你自己了。這個時候如果你掌握了一些快速熟悉專案的技巧，會對你有很大幫助。
否則，因為沒能在一定時間內對專案有足夠的瞭解，導致工作完成得不好，進一步導致沒過試用期，那就麻煩大了。
很多人熟悉專案，先從其中用到的中介軟體開始。這個思路其實不太好，雖然中介軟體是通用的，在哪個專案裡都能用，所以比較容易下手。但是具體怎麼用，承擔了什麼職責，在一些細節上，不同專案會有所不同。
所以從中介軟體入手去熟悉專案，就猶如管中窺豹，瞭解的並不全面，甚至可能會判斷錯誤。
在 Z 哥的職業生涯中，大多數時候都沒有什麼人來指導，自己摸石頭過河熟悉過大大小小十幾個專案，也積累了一些經驗，在這裡和大家交流一下。也歡迎你在評論區分享你的好方法。
我的思路總共分為 5 步。我相信，沿著這個思路來熟悉專案，不敢說對專案瞭如指掌吧，至少可以在短時間內瞭解專案的 6、7 分。
/01 從哪裡來/
“從哪裡來，到哪裡去”是一個著名的哲學問題，其實這個邏輯也適用於我們熟悉一個陌生專案。
大部分情況下，技術都是為業務服務的，所以任何專案都是為了解決某一個問題而誕生的，因此，「從哪裡來」自然藏在業務裡。
建議可以從以下兩個問題入手，搞清楚了這兩個問題，相信你也知道了這個專案的由來。
誰在用這個系統？
用這個系統做什麼？
其實你會發現，這兩個問題構建的是一個畫面，一個人或者一群人在如何使用這個系統進行工作的畫面。這其實就是所謂的工作場景，它們也解答了「從哪裡來」這個問題。
舉個例子，比如說你接手了一個訊息通知類的系統，那麼經過了解會得到這樣的一條資訊。
運營人員會用這個系統傳送APP通知、簡訊通知等，以此來觸達消費者，並引導使用者促成交易轉化。
進一步你也會知道，這個系統的職責就是編輯通知內容、傳送通知、記錄觸達的結果。如果更進一步的話，還能考慮到點選率、轉化率等資料記錄，因為這些資料可以更好的幫助操作人完成他的工作目的，“促成更多的交易”。
/02 到哪裡去/
第一步搞清楚了「從哪裡來」，下一步搞清楚「到哪裡去」。
「到哪裡去」就是搞清楚這個專案生命週期，這個專案實際是如何運轉創造價值的。這其實也是必要的一個前期準備工作。畢竟不管做任何事，有準備總是更好的。沒有準備，談何事半功倍呢。
第一步主要需要做兩件事：
知道原始碼在哪裡。
搞清楚專案執行涉及到的環境。這裡的環境不僅僅是生產環境，還有各個測試環境和 CI / CD 機制。
只要知道了這兩項內容，其實你對這個專案的「生命週期」就瞭解的很清楚了。知道了它是如何流轉的，就相當於知道了它到哪裡去。
/03 梳理技術鏈路/
在第一步中我們做的工作其實間接也算梳理了一遍業務鏈路。基於這個資訊其實我們也可以進行技術鏈路的梳理了。
對於技術鏈路的梳理，我的建議是，「先縱再橫」。
「縱」就是沿著一條線從前往後梳理，一般從應用側開始， 應該很多人也的確是這麼幹的。比如上面我們在前面例子中提到的通知系統，一般是，UI -> API -> MQ / DB -> 各個通知渠道的 Service -> DB。
「橫」就是對梳理出來的多條「縱」的技術鏈路進行整理，找到其中的共同點以及相關性。這些共同點大多會由一個通用元件/ Service 來滿足需求，而相關性則代表著多個業務鏈路之間的「耦合」關係。
當然，如果你參與到的是一個超大型專案，很多「縱」其實已經單獨做成一個子系統了，這個時候對「橫」的梳理，其實就是對子系統之間的梳理。
注意，做技術鏈路梳理的時候，不需要陷入到程式碼細節裡去，只要大致知道不同 class 之間的引用關係如何即可。如果你提前深入到程式碼細節裡去，那麼一但遇到複雜度較高的專案，你很容易產生焦慮感。
/04 梳理資料表/
如果說站在整個業務的本質上看，業務無非就是一堆程式碼執行在一堆機器上；那麼站在單個專案來看，一個專案無非就是對資料庫的增刪改查操作而已；或者從使用者的角度看，一個專案就是輸入一些引數得到一些返回結果而已。
工欲善其事必先利其器，梳理資料表我平時最喜歡用的工具是 Red Gate 裡的 SQL Doc 和 SQL Dependency Tracker。前者可以自動根據資料庫的資訊生成方便檢視的文件，後者可以生成圖表檢視資料之間的關係，很好用。
如果遇到一個表數量達到 3 位數的時候，怎麼能快速定位核心表呢，有 2 個小技巧。
忽略 config、log、flow、statistics 為字尾或者字首的表，這些的表的作用從名字也能看出來作用，必然不會包含什麼核心業務資訊。
從一些字首統一的表，但是字首不屬於上面 4 個單詞的表開始。比如 order、trade 這種，一般越核心的業務，往往基於它字首所擴展出來的表也越多。
/05 執行並除錯一下/
除錯是一個有效的 Debug 方式，也是一個有效理解程式碼的方式。我們進行除錯的目的倒不是為了弄清楚某一個業務的細節，而是透過除錯來觀察資料的流轉情況，驗證自己對之前做的這些資訊整理所形成的猜想是否屬實。
因此，儘量挑選一個你認為業務最複雜的頁面，然後對頁面上的每個按鈕都去點一下看看。在這個期間你還能加強對前後端之間通訊方式的理解。
前陣子寫過一篇《幫助閱讀原始碼的8個技巧》，裡面有些思路其實是類似的。
最後再多說幾句感想，我知道有很多人在熟悉專案的時候會吐槽原來的設計多麼多麼垃圾。我勸大家善良，因為可能未來接手你現在負責的這個專案的人也會這麼吐槽你。但實際上我相信每個人在當時作出的決策設計，一定是在當時綜合各方因素後的最優解，畢竟沒有人那麼傻，明知故錯。
另外，以下這三點也是在我們熟悉專案的過程中可以相信的事情。
你遇到的問題很多人已經遇到過並且解決了 。
你遇到的問題大機率在當前系統裡面已經有了答案。
你遇到的問題大機率在你用的框架和元件裡面都有現成的解決方案。
好了，總結一下。
這篇呢，Z 哥和你分享了我對如何快速熟悉一個專案的經驗。我的思路主要分為 5 步：
從哪裡來
到哪裡去
梳理技術鏈路
梳理資料表
執行並除錯一下
希望對你有所幫助。
對很多人來說，更願意重頭做一個新系統而不是去接手一個老系統。不過，老系統其實滿是寶藏，裡面有很多你可以借鑑和學習的東西。
推薦閱讀：
我是這樣做資料分析的
對DDD的常見誤區
也可以「關注」我，帶你以技術思維看世界～
想更進一步和我一起玩耍，歡迎「搜尋微信公號：跨界架構師」。
內容包括：架構設計丨分散式系統丨產品丨運營丨個人深度思考。
