程序員隨想-快速熟悉業務

前言

做爲一名開發，常常面臨着主動或被動切換業務作，有些時候切換至有必定相關聯的另外一個業務，原本作餘額寶的被調到作證券。一些狀況下是切換至徹底相關的業務，如從商品切換到交易，甚至從電商業務切換至金融業務。在常常遇到這種的狀況下，創建一個「快速熟悉陌生業務」的方法論就很重要了。下面通過我的思考，提出的一些不完善的想法。

1、劃分模塊

人的記憶和關係型數據庫有些類型，較容易記住的大的關鍵點，而具體的細節可能想好久，甚至記不住。根據人的這種記憶方式，咱們接觸一個新的事務最好的方式應該就是分層，按照必定邏輯分幾層，每層分多個模塊，瞭解每層各個模塊概念，而後再細分下一層子模塊概念。這種思惟方式有點像數據庫的索引，符合人的思惟習慣。

劃分模塊方式

模塊是基於必定邏輯組織形式來劃分的，只要按照邏輯來劃分的話，劃分模塊的方式確定有不少種，這裏我提兩種最容易的方式：業務功能，應用架構。

業務功能

按照業務功能性，對業務進行拆解，把複雜的業務進行拆分紅功能單元，各功能單元再根據場景進行更細粒度的拆分。拆分有一個原則，要作到高內聚，低耦合。

應用架構

基本上應用都是分層的，下圖就是最多見的應用的組織形式，固然不少應用組織形式會根據具體狀況進行變化

2、梳理業務領域模型

對於大部分人結束新的業務的時候，相信最麻煩的就是周圍人談論的「專業詞彙」，像以前聽得什麼，直銷、代銷，轉託管，卡帳，戶賬這類詞彙對於第一次聽到人確定矇蔽。對於這一類詞彙其實不少都是特定業務領域造成的簡化術語，若是連這些業務領域內的概念的不清楚，那麼根本不知道在討論一個什麼事。這類詞彙存在於特定業務領域中，瞭解業務領域是至關重要的，統一你們的概念認知，統一你們在討論的是一件什麼事，在作的是一件什麼事！！

因此我說的要了解業務領域，並非指得DDD，充血、貧血模型。而是對業務進行必定抽象成一個或多個有關聯的業務模型，對於這個模型有必定認知是需求討論和方案設計的前提，不少時候某個業務域用到了其餘業務域的模型，那麼相對於相關聯業務域的模型也要有必定認知。

如何梳理業務領域模型？

業務領域模型最底層的是數據庫表極其字段，把表和表之間的關係，字段含義理清楚後，會有大概的業務輪廓。接着經過熟悉模塊中核心的POJO的類極其字段能更對業務有更清晰一點的認知。固然這還不夠，還須要花時間去看一些集團，網上的文章，關於其餘人對業務的理解，其餘人在技術如何設計和實現的。這個過程不是一蹴而就的，慢慢的會找到更深的理解，等到了能發現當前這個業務領域模型優勢缺點，並構思出改進的方向，基本上就意味已經進入這塊業務領域的專家了。

3、梳理業務調用鏈路

尋找業務入口，而後看代碼。通常來講業務代碼迭代很快，不少在寫代碼的時候沒有考慮之後，常常被以後的需求給推翻調，亦或者經歷過多個團隊多人接手過，每一個人命名、設計等等習慣不同，因此這個過程比較痛苦。

如何梳理業務調用鏈路？

這裏必需要提一下，traceId是個神器，本身實際操做一筆拿到traceId，在集團鷹眼或者螞蟻雲圖上應用的調用鏈路基本上呼之欲出，可是具體邏輯細節仍是要本身去看代碼。這裏看代碼我理解兩種模式，一種是自下而上，另外一種是自上而下。我比較喜歡自上而下的看，這樣順着業務鏈路來理解比較簡單，大部分狀況下二者結合效果比較好。

自上而下

先後端不分離的PC頁面，順着頁面實際操做入口去看，很簡單 先後端分離的PC頁面、Ajax接口、無線端，和前端同窗打好關係，多聊聊，喝喝咖啡，讓前端同窗幫忙去找入口，另外就是經過網絡抓包找到調用入口，順着代碼往下看吧，少年。經過日誌裏面的traceId能夠查到調用鏈路甚至到接口級別，這就更方便找到入口。通常狀況下相同功能模塊、對外的接口會放在一個大包或者pom模塊下面。

自下而上

從數據庫表入手，理解表模型，各字段含義，創建各表和字段之間的關係。

4、需求入手

通常狀況下，公司不太會給太多空閒時間去看代碼，且直接看代碼多數狀況下也沒有那麼直觀感覺，這時候結合一些比較完整的需求去搞，效果反而會更好。所謂完整的需求是指：儘可能是完整模塊的需求，或者能串聯部分或整個鏈路的需求。切身體驗零散的需求沒有鳥用。