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

[[320916]]

前言

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

• 新人入職，需要學習已有系統，作為 landing 的一部分，如何學習?
• 被拉過去參與一個陌生系統的迭代開發或者系統維護(bugfix)，如何快速上手?
• 同事離職或轉崗，需要把系統交接給你，怎么去接?內心 os：這是一口鍋嗎?

[[320917]]

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

業務學習

業務學習就是從業務角度去學習系統，我們需要了解系統的客戶是誰、使用人是誰、帶來了什么價值，系統提供了哪些功能等。不清楚業務，就等于不知道系統在干什么。技術是為業務落地而服務，清楚了業務才知道怎樣用技術更好地服務業務，所以業務學習是熟悉一個系統的首要任務。這塊主要的學習方式有跟產品、運營、開發溝通，學習產品設計文檔文檔、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 的建設過程，熟悉系統其實是一個逆向推導過程，也是一個學習架構、閱讀源碼的過程。在學習的過程中最好能帶上思考，比如為什么要這么設計，為什么要用這個中間件?是否有更好的編碼方式?哪些地方可以優化等，以此達到一個深入熟悉的過程。