面對一個徹底陌生的系統，如何快速的熟悉並上手?

面對一個徹底陌生的系統，如何快速的熟悉並上手?本文將從三個方面進行總結，提供一個系統的方法，同時也能夠用來 review 已有的系統，查漏補缺。

前言

開發人員常常會面臨下面一些場景：

• 新人入職，須要學習已有系統，做爲 landing 的一部分，如何學習?

• 被拉過去參與一個陌生系統的迭代開發或者系統維護(bugfix)，如何快速上手?

• 同事離職或轉崗，須要把系統交接給你，怎麼去接?心裏 os：這是一口鍋嗎?

這樣的場景多了，就須要去梳理常見問題以及應對方法，方便後續遇到相似場景能夠快速應對。本文總結熟悉系統主要分三部分：業務學習、技術學習、實戰。每部分會梳理一些在學習過程當中須要解答的問題，這些問題隨着經驗的積累須要逐步補充完善。

業務學習

業務學習就是從業務角度去學習系統，咱們須要瞭解系統的客戶是誰、使用人是誰、帶來了什麼價值，系統提供了哪些功能等。不清楚業務，就等於不知道系統在幹什麼。技術是爲業務落地而服務，清楚了業務才知道怎樣用技術更好地服務業務，因此業務學習是熟悉一個系統的首要任務。這塊主要的學習方式有跟產品、運營、開發溝通，學習產品設計文檔文檔、PRD、本身使用系統，還有一些常見圖，如產品功能架構圖、業務流程圖、功能樹，用例圖等。

常見問題：

• 系統所在行業的狀況是怎樣?

• 系統的目標用戶是誰?好比是給公司高層作決策用?給運營或客服用?仍是互聯網用戶用?

• 平均有多少人在使用?高峯期多有少人在用?

• 系統有什麼業務價值?有哪些指標能夠衡量系統業務價值?

• 系統有哪些功能模塊?

• 系統有哪些領域概念?梳理下系統的領域模型。

• 系統的關鍵業務流程有哪些?關鍵業務流程是怎樣?

• 系統的非功能性需求有哪些?如性能、質量、擴展性、安全性等。

• 系統將來的發展規劃是怎樣?

技術學習

技術學習主要學習系統的架構、如何實現、系統的運維等。描述一個系統的架構有五視圖方法論，五視圖分別是：邏輯架構、開發架構、運行架構、物理架構、數據架構。

邏輯架構

邏輯架構着重考慮功能需求，系統應當向用戶提供什麼樣的服務，關注點主要是行爲或職責的劃分。經常使用表達圖形，靜態圖有包圖、類圖、對象圖，動態圖有序列圖、協做圖、狀態圖、活動圖。邏輯架構的核心設計任務是模塊劃分、接口定義、領域模型細化。

常見問題：

• 有哪些子系統或模塊?系統之間是什麼樣的關係?

• 對外上下游接口有哪些?對接人是誰?

• 關鍵業務流程怎麼實現的?用類圖、序列圖等方式表達出來。

開發架構

開發架構關主要關注系統源代碼、第三方SDK、使用的框架、中間件、工具包。

常見問題：

• 代碼在哪?

• 包怎麼劃分的?怎麼分層?如 mvc、controller-service-dao。

• 用了什麼框架?如 ssh、dubbo。

• 用了哪些工具包?如 apache commons、guava。

• 用了哪些中間件?如 metaq、tair、schedulerX、Diamond。

• 依賴哪些平臺?如權限平臺、流程引擎等。

運行架構

運行架構的着重考慮運行期質量屬性，關注點是系統的併發、同步、通訊等問題，這勢必涉及到進程、線程、對象等運行時概念，以及相關的併發、同步、通訊等。

常見問題：

• 系統能支撐多少 qps ?峯值 qps 多少?

• 與上下游系統怎麼交互的?rpc?http?同步仍是異步?

物理架構

物理架構的設計着重考慮安裝和部署需求，關注點是目標程序及其依賴的運行庫和系統軟件最終如何安裝或部署到物理機器，以及如何部署機器和網絡來配合軟件系統的可靠性、可伸縮性、持續可用性、性能和安全性等要求。

常見問題：

• 系統如何發佈部署?有哪些部署環境?

• 系統有多少臺機器?

• 系統部署怎麼部署的?關注接入層，部署方式，如集羣部署、分佈式部署等。

• 有沒有容器化?

• 有沒有多機房部署?

數據架構

數據架構的設計着重考慮數據需求，關注點是持久化數據的存儲方案，不只包括實體及實體關係數據存儲格式，還可能包括數據傳遞、數據複製、數據同步等策略。

常見問題：

• 數據存儲在哪?用了什麼數據庫，如 oracle、mysql。

• 梳理 E-R 圖。

• 數據量有多少?是否有分庫分表?

• 用了哪些 nosql 庫?

• 有哪些數據同步任務?

• 大數據框架的使用狀況如何?

系統運維

系統運維重點關注何時會出問題，出了問題怎麼解決。

常見問題：

• 什麼時間容易出問題?好比電商雙十一，對系統的壓力很大，這時候很容易出問題。

• 對關鍵功能是否有監控?須要看系統有配置了哪些報警項，監控了哪些方面。

• 出了問題怎麼解決?日誌在哪?是否有全鏈路跟蹤?是否有一些緊急操做，好比開關配置、降級、限流配置。

• 系統有哪些坑?找開發同窗回顧歷史問題，以避免踩坑。經過同事總結的 case，或者與負責的產品、運營、技術與瞭解。系統總會有一些坑，須要把這些坑填上。歷史代碼通過屢次迭代總會致使複雜度高(分支、嵌套、循環不少)，存在設計漏洞，性能隱患等，很難維護，這些就須要咱們去重構了。記住有一句話：填的坑越大，能力越大。

• 運營、客服反饋的常見問題有哪些?

實踐

熟悉了系統的業務和技術後，就要實戰了，經過實戰進一步加深對系統的熟悉程度。實踐能夠經過作需求、修 bug、重構等方式，親自動手編碼、調試、測試、上線。

總結

已有系統一般經歷了從 0 到 N 的建設過程，熟悉系統實際上是一個逆向推導過程，也是一個學習架構、閱讀源碼的過程。在學習的過程當中最好能帶上思考，好比爲何要這麼設計，爲何要用這個中間件?是否有更好的編碼方式?哪些地方能夠優化等，以此達到一個深刻熟悉的過程。