作者：范文杰

簡介：字節(jié)跳動前端工程師

來源：SegmentFault 思否社區(qū)

我很早就意識到，能熟練、高效閱讀開源前端框架源碼是成為一個高級前端工程師必須具備的基本技能之一，所以在我職業(yè)生涯的最早期，就已經(jīng)開始做了很多次相關(guān)的嘗試，但結(jié)果通常都以失敗告終，原因五花八門：

缺乏必要的背景知識，猶如閱讀天書
不理解項目架構(gòu)、設計理念，始終不得要領
目標不夠聚焦，閱讀過程容易復雜化
容易陷入細節(jié)，在不重要的問題上糾結(jié)半天
容易追著分支流程跑，分散注意力
沒有及時記錄筆記和總結(jié)，沒有把知識碾碎、重組、內(nèi)化成自己的東西
沒有處理過特別復雜問題的經(jīng)歷，潛在的不自信心理
個人毅力、韌性不足，或者目標感不夠強烈，遇到困難容易放棄
等等

這個列表還可以繼續(xù)往下拉很長很長，總之既有我自己主觀認知上的限制又有切切實實的客觀原因。后來因為工作的契機硬著頭皮看完 Vue 和 mxGraph 的源碼，發(fā)現(xiàn)事情并沒有自己想象中那么困難，后來前前后后陸續(xù)看了很多框架源碼，包括 Webpack、Webpack-sources、Vite、Eslint、Babel、Vue-cli、Vuex、Uniapp、Lodash、Vetur、Echarts、Emmet 等等，愚鈍如我也慢慢摸索出了一些普適的方式方法，進而斗膽撰下這篇文章，不敢說授人以漁，但至少也該拋磚引玉吧。

所以這是一篇為哪些有意，或準備，或已經(jīng)在閱讀前端框架源碼的同學而寫的文章，我會在這里拋出一些經(jīng)過我個人多次實踐總結(jié)出來的閱讀技巧和原則，并結(jié)合 Vetur 源碼，具體地講解我在閱讀源碼的各個階段所思所想，希望能給讀者帶來一些啟發(fā)。

弄清楚目標

在介紹具體的技巧之前，有必要先跟讀者探討一下閱讀源碼的動機，想清楚到底需不需要通過這種方式提升自身技能，雖然學習優(yōu)秀框架源碼確實有非常多不言自明的好處，但每個人的經(jīng)驗、所處的語境、訴求、思維習慣不同，實際學習效果在不同個體或個體的不同時期必然存在極大的差異，這里面最大的變量一是經(jīng)驗，二是目標，經(jīng)驗因人而異，且很難在短時間內(nèi)補齊，沒有太多討論空間；倒是目標方面值得盤道盤道。

第一層，先弄清楚為啥要閱讀源碼？可能的原因有很多，例如：

為了增進對框架的認知深度，提升個人能力
為了應對面試
為了解決當下某個棘手的 bug 或性能問題
基于某些原因，需要對框架做二次改造
反正閑著，也不知道該學點啥，試試唄。。。
好奇

這里面有一些很抽象，例如最后一個“好奇”；有一些很具體，例如“為了做二次改造”；還有一些在具體與抽象之間。按照 SMART 原則的說法，越具體、可衡量的目標越容易達成，如果讀者的目標還處在比較模棱兩可，不夠具體詳細的階段，那執(zhí)行過程大概率會翻車，畢竟這是一件特別消耗精力與耐性的活兒。

對于這種情況，我的建議是不妨往更細節(jié)的層次再想一想，例如對于最后一點“好奇”，可以想想具體有哪些特性讓你特別神奇，值得花時間精力去細致地探索，放在 Vetur 語境下可以是“我想了解 Vetur 的 template 錯誤提示與 eslint 如何結(jié)合在一起，實現(xiàn)模板層面的錯誤提示功能”，這就很具體很容易衡量了。

第二層，讀者如果已經(jīng)有了明確、具體、可衡量的目標，不妨在開始之前先自問幾個問題：

當下確實需要以閱讀源碼的方式增進自己對框架的認知深度嗎？有沒有一些更輕量級，迭代速度更快的學習方式？
你所選定的框架，其復雜度、技術(shù)難度是否與你當下的能力匹配？最好的狀態(tài)是你自認為踮踮腳就能夠到，過高，不具有可行性；過低，ROI 不值當。

如果經(jīng)過這番推敲之后，必要性、可行性、相關(guān)性都與個人目標契合，那就沒啥可猶豫的。

第三層，需要辯證地去看待所謂“目標” —— 不是把整個項目完整讀完讀通才叫成功，如果能從一些語句、片段、局部模塊中習得新的設計思維、工具方法，甚至僅僅是命名規(guī)范都可以算作個人的一點進步，積少成多遠比拔苗助長靠譜的多。所以一開始沒必要把目標定的太高，能剛剛好滿足自身需求是最好的，過程中如果發(fā)現(xiàn)問題域的復雜度在不斷膨脹變大，持續(xù)投入很多時間卻始終沒有明顯成效的話，那建議果斷放棄或者請求外援，重新評估目標與可行性之后再做決定。

總之，這是一個預期管理的問題，我們可以多參考 SMART 原則，多從具體、可衡量、可行性、相關(guān)性幾個維度思考，不斷推敲是否需要做這件事；如何拆解目標，用目標反推計劃，不斷推進個人成功。

閱讀技巧

了解背景知識

知識是形成理解的必要條件，展開學習任何一個開源項目之前都有必要花點時間調(diào)研項目相關(guān)的基礎知識，漸進構(gòu)建起一套屬于你自己的知識體系，這包括：

優(yōu)質(zhì)參考資料 —— 收集一波質(zhì)量較高的學習資料，收集過程可以同步通讀一遍
框架是如何運行的 —— 也就是所謂的入口
IO —— 框架如何與外部交互？它通常接受什么形態(tài)的運行參數(shù)？輸出什么形式的結(jié)果？
生態(tài) —— 優(yōu)秀的框架背后通常都帶有一套成熟的生態(tài)系統(tǒng)，例如 Vue，框架衍生品如何補齊框架本身的功能缺失？它們以何種方式，以什么樣的 IO 與主框架交互？遵循怎么樣的寫法規(guī)則？
如何斷點調(diào)試 —— 這幾乎是最有效的分析方法，斷點調(diào)試能夠幫助你細致地了解每一行代碼的作用。

注意，這里的目標是迅速構(gòu)建起關(guān)于這個開源項目的抽象 —— 甚至不太準確的知識框架，有意思地避免陷入無盡的細節(jié)中，就像在閱讀一篇文章的時候，可以先看看目錄結(jié)構(gòu)粗略地了解文章的信息框架，了解文章大概內(nèi)容。

例如，我剛開始學習 Vetur 的時候只知道這是一個 VS Code 插件，但完全不了解插件怎么寫、怎么運行、怎么實現(xiàn)語言特性，所以我做的第一件事情是仔仔細細閱讀 VS Code 的官方文檔(所幸文檔非常齊全，不像某著名打包工具)，學習關(guān)于插件開發(fā)的基本知識，包括：

進一步總結(jié)關(guān)于 VS Code 語言插件的要素：

怎么寫插件：通過 package.json 文件的 contributes 、main 等屬性，聲明插件的功能與入口
怎么運行：開發(fā)階段使用 F5 啟動調(diào)試
怎么編寫語言特性：使用 詞法高亮、Language API、Language Server Protocol 三類技術(shù)實現(xiàn)

VS Code 領域的知識量還是很龐大的，學習背景知識并梳理成這種高度結(jié)構(gòu)化、高度抽象的腦圖能夠給你一個更高層、全面的視角，理想狀態(tài)下，后續(xù)實際分析源碼的時候這些骨架脈絡能夠讓你非常本能地映射到某一個切面的知識點，事半功倍。

六步循環(huán)分析

接下來，我會介紹一套我常用的分析流程：

整體分為六個步驟：

理解項目結(jié)構(gòu)
尋找合適的切入點
就著切入點查閱文章資料
就著切入點分析代碼流程
局部深入研究
及時總結(jié)
之后，再繼續(xù)設定切入點，重復執(zhí)行上述流程直到透徹地理解了問題

這是一套在 總-分-總 視角之間反復橫跳最終構(gòu)建出完整視角的方法論，重點就在于告訴讀者在什么階段應該關(guān)注什么，忽略什么，輸入什么，輸出什么，我個人就是按照這個方法慢慢摸索出包括 Webpack、Babel、Vue、Vetur、mxGraph 在內(nèi)的各種開源框架的實現(xiàn)原理。

理解項目結(jié)構(gòu)

剛開始閱讀源碼的時候，相信大多數(shù)人都會很懵逼，無從下手，這是因為讀者對項目缺乏一個必要的框架性認知，不了解程序的入口在哪里、關(guān)鍵組件有哪些、各個文件夾有什么作用等，遇到問題無法迅速推測實現(xiàn)路徑。

所以，閱讀源碼的第一個步驟，應該是先花點時間粗淺地分析、理解項目的組織結(jié)構(gòu)。所幸一個值得深入閱讀學習的開源項目，通常都會有較強的整體性與一致性，我們只需要梳理出三條線索：

分析項目入口
分析項目依賴了哪些基礎工具，包括編譯工具，如 webpack、Typescript、babel；基礎庫，如 lodash、tapable、snabbdom。
將項目中重要文件夾、文件逐一列舉出來，理解它們?nèi)绾伟凑找蕾囮P(guān)系組成一個整體的架構(gòu)。

放在 vetur 語境下，我們在上面“了解背景知識”一節(jié)已經(jīng)了解到 VS Code 插件需要在 package.json 文件通過 contributes 等屬性聲明插件的配置信息，所以這幾個問題都能在 package.json 文件找到答案。

入口分析

首先，需要識別出 Vetur 應用的入口，這一步的作用是幫助我們理解 Vetur 是如何向 VS Code 貢獻新特性的。分析 vetur 的 package.json 發(fā)現(xiàn)有三種直接指向到文件的配置項：

contributes.languages 指定語言配置文件
contributes.grammars 指定語法配置文件
"main": "./dist/vueMain.js" 指定插件執(zhí)行入口

三個入口分別實現(xiàn)三種不同的語言特性功能，略顯復雜，這里有必要分別展開了解一下。

探索 contributes.languages 配置

逐個講解，contributes.languages 配置信息指向到 ./languages/***-language-configuration.json 文件，如：

{
    // ...
    "contributes": {
        "languages": [
            {
                "id": "vue",
                "configuration": "./languages/vue-language-configuration.json"
            },
            {
                "id": "vue-html",
                "configuration": "./languages/vue-html-language-configuration.json"
            }
            // ...
        ]
    }
    // ...
}


這里回過頭翻一下 VS Code 對 [contributes.languages] 的解釋：

Contribute definition of a language. This will introduce a new language or enrich the knowledge VS Code has about a language.

大意是說 contributes.languages 配置項的作用主要是增進 VS Code 對具體語言的理解，至于怎么增強呢？繼續(xù)打開配置項中的 ./languages/vue-language-configuration.json 文件：

{
    "comments": {
        // symbol used for single line comment. Remove this entry if your language does not support line comments
        "lineComment": "http://",
        // symbols used for start and end a block comment. Remove this entry if your language does not support block comments
        "blockComment": [
            "/*",
            "*/"
        ]
    },
    // ...
}

文件中定義了行內(nèi) comment、塊級 comment、括號、折疊等語言規(guī)則的配置，規(guī)則都很簡單直白，篇幅關(guān)系這里不展開。

回顧一下探索步驟：

翻閱參考資料，理解 contributes.languages 配置的作用
打開對應入口文件，猜測各個配置項的作用
繼續(xù)翻閱參考資料，或者修改配置，驗證猜想

探索 contributes.grammars 配置

contributes.grammars 項包含諸多指向到 ./syntaxes/vue-xxx.json 的配置信息，形如：

{
    "contributes": {
      "grammars": [
        {
          "language": "vue",
          "scopeName": "source.vue",
          "path": "./syntaxes/vue-generated.json",
          "embeddedLanguages": {
            "text.html.basic": "html",
            // ...
          }
        },
        {
          "language": "vue-postcss",
          "scopeName": "source.css.postcss",
          "path": "./syntaxes/vue-postcss.json"
        }
        // ...
      ]
    }
  }

同樣的，我們先查一下官網(wǎng)對 [contributes.grammars] 配置項的解釋：

Contribute a TextMate grammar to a language. You must provide the language this grammar applies to, the TextMate scopeName for the grammar and the file path.

這段描述略微復雜，大意是開發(fā)者可以通過 grammars 屬性提供關(guān)于語言的 TextMate 形式的語法描述，grammars 配置項包含三個屬性：

language：語言的名稱
scopeName：語言的分類，與 TextMate scopeName 同義，可用于嵌套語法定義
path：語言的詞法規(guī)則文件

這里面 path 屬性指向一個內(nèi)容更復雜的配置文件 ./syntaxes/vue-xxx.json，我們可以接著打開其中任意一個文件，關(guān)鍵內(nèi)容結(jié)構(gòu)如下：

{
    "name": "Vue HTML",
    "scopeName": "text.html.vue-html",
    "fileTypes": [],
    "uuid": "ca2e4260-5d62-45bf-8cf1-d8b5cc19c8f8",
    "patterns": [
        // ...
        {
            "name": "meta.tag.any.html",
            "begin": "(<)([A-Z][a-zA-Z0-9:-]*)(?=[^>]*></\\2>)",
            "beginCaptures": {
                "1": {
                    "name": "punctuation.definition.tag.begin.html"
                },
                "2": {
                    "name": "support.class.component.html"
                }
            }
        }
    ],
    "repository": {
        // ...
    }
}

按照 Syntax Highlight Guide 一節(jié)的說法這里面最重要的是 patterns 屬性，而 patterns 屬性最關(guān)鍵的功能就是以正則語句表達語言的詞法分析規(guī)則，并分配詞法對應的 name 命名，詳細的配置規(guī)則還可以繼續(xù)參考 TextMate 官網(wǎng)，這里大致理解作用即可，先不展開深究。

探索 main 配置

接著往下看，第三個值得關(guān)注的是 main 屬性，在 vetur 中對應的值為：

"main": "./dist/vueMain.js"

VS Code 官網(wǎng)對 main 屬性的解釋非常精簡：The entry point to your extension，也就是插件的入口，通常需要指向到可執(zhí)行的 JS 文件，插件啟動時 VS Code 會執(zhí)行這個入口文件導出的 activate 方法，內(nèi)容框架大致為：

import vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {
    // ... 啟動邏輯
}

在 Vetur 中，activate 函數(shù)定義在 client/vueMain.ts 文件，分析源碼可知該函數(shù)主要完成如下事項：

調(diào)用 registerXXXCommands 方法注冊一系列命令
調(diào)用 initializeLanguageClient 方法初始化 LSP Client 對象

這兩個操作具體的作用，我們先按下不表，后面再展開。

小結(jié)

對入口的分析就到這里了，我們先總結(jié)、記錄下關(guān)鍵信息：

Vetur 本質(zhì)上是一個 VS Code 插件，所有配置 —— 包括入口都記錄在 package.json 文件中
Vetur 包含三種啟動入口：

contributes.languages：定義一些簡單的語言基本配置，包括怎么折疊，怎么注釋
contributes.grammars：定義了一套基于 TextMate 引擎的詞法規(guī)則，用于實現(xiàn)代碼高亮
main：定義了插件的啟動入口，入口中注冊了一系列命令，同時創(chuàng)建了基于 LSP 協(xié)議的 Language Client 對象，而 LSP 協(xié)議用于實現(xiàn)如代碼補全、錯誤診斷、跳轉(zhuǎn)定義等高級特性

到這里，雖然我們還是不了解 Vetur 的實現(xiàn)細節(jié)，但是對 Vetur 的背景知識與項目結(jié)構(gòu)應該已經(jīng)有了一個比較基礎的認知，已經(jīng)能大致識別哪些功能由哪些模塊實現(xiàn)。

OK，這里先保持好這個模模糊糊的認知就行了，不要花太多時間。

基礎依賴分析

接下來，需要梳理一下 Vetur 的基礎依賴，這一步的作用是幫助我們理解 Vetur 可能用到哪些基礎技術(shù)，比如用到哪些工程化工具、怎么編譯、怎么檢查代碼等。

Vetur 的 package.json 文件主要包含三類信息：

VS Code 插件配置信息，大體上在上一節(jié)都有描述，這里不展開
工程化命令，核心有：

watch：對應命令為 rollup -c rollup.config.js -w ，由此可以推斷 Vetur 基于 Rollup 實現(xiàn)構(gòu)建
compile：功能與 watch 相似
lint：對應命令為 tslint -c tslint.json **.ts ，由此可以推斷 Vetur 基于 tslint 實現(xiàn)代碼檢查

項目的 devDependencies 依賴，主要包含 typescript、tslint、rollup、vscode-languageclient、husky、mocha、vscode-test、prettier

那么，從這些信息我們基本可以推斷出如下信息：

Vetur 使用 Rollup + typescript 等工具執(zhí)行構(gòu)建工作，按常理執(zhí)行 yarn watch 命令應該就能啟動一個持續(xù)的構(gòu)建工作進程
Vetur 使用 tslint 實現(xiàn)代碼檢查，配合 huscky + prettier 完成格式化工作
Vetur 使用 mocha + vscode-test 實現(xiàn)自動化測試

文件結(jié)構(gòu)

接著，還需要稍微展開看看 Vetur 的文件結(jié)構(gòu)，這一步能夠一定程度上幫助我們理解 Vetur 的代碼架構(gòu)及要素，推測各種特性是在什么位置實現(xiàn)的。Vetur 的文件結(jié)構(gòu)大致上如下：

vetur
├─ .vscode
│  ├─ ...
├─ build
│  ├─ ...
├─ client
│  ├─ client.ts
│  ├─ commands
│  │  ├─ ...
│  ├─ grammar.ts
│  ├─ ...
├─ languages
│  ├─ vue-html-language-configuration.json
│  ├─ ...
├─ scripts
│  ├─ build_grammar.ts
│  └─ tsconfig.json
├─ server
│  ├─ .gitignore
│  ├─ .mocharc.yml
│  ├─ .npmrc
│  ├─ bin
│  │  └─ vls
│  ├─ package.json
│  ├─ rollup.config.js
│  ├─ src
│  │  ├─ ...
├─ syntaxes
│  ├─ markdown-vue.json
│  ├─ pug
│  │  ├─ ...
│  ├─ ...
│  └─ vue.yaml
├─ test
│  ├─ ...
├─ vti
│  ├─ README.md
│  ├─ bin
│  │  └─ vti
│  ├─ package.json
│  ├─ rollup.config.js
│  ├─ src
│  │  ├─ ...
│  ├─ tsconfig.json
│  └─ yarn.lock
├─ tsconfig.options.json
├─ package.json
├─ ...
└─ yarn.lock

其中，比較關(guān)鍵的有：

client：VS Code 插件的入口代碼，package.json 文件中 main 字段會指向這個目錄的產(chǎn)物
server：LSP 架構(gòu)中的 Server 端，上述 client 會通過 LSP 協(xié)議與這個 server 目錄通信
syntaxes：Vetur 的詞法規(guī)則文件夾，內(nèi)部包含許多 JSON 格式，符合 TextMate 規(guī)則的詞法聲明
languages：Vetur 提供的語言配置信息，規(guī)則比較簡單，了解作用即可，不必深入
vti：按 vti/bin/vti 文件可以推斷，這里是 Vetur 的命令行工具，不在主流程內(nèi)可以先忽略
docs：按內(nèi)容可以推斷這是 Vetur 的介紹文檔，此處可忽略
build：構(gòu)建命令，package.json 文件的 script 命令有一些會指向這個目錄，可以忽略
一系列基礎配置文件，包括 tsconfig.json 、package.json 等，可先忽略

我們還可以繼續(xù)往下探索各個子目錄的內(nèi)容，但是注意淺嘗輒止即可，后面隨著源碼閱讀的深入，讀者對各個目錄的理解應該會不斷迭代增長，現(xiàn)在沒必要花太多時間。

小結(jié)

回顧一下，我們首先學習了一些背景知識，之后花了一些時間分析項目的入口、基礎依賴、文件結(jié)構(gòu)，到這里我們基本上可以推斷出：

Vetur 是一個語言插件，所以必然是使用 詞法高亮、Language API、Language Server Protocol 三類技術(shù)實現(xiàn)核心邏輯的，而 package.json 文件中的 contributes 配置項的內(nèi)容也恰好驗證了這一點
詞法高亮 相關(guān)的代碼集中在 syntaxes 文件夾
Language Server Protocol 相關(guān)的代碼集中在 client 與 server 文件夾
可以用 yarn watch 命令持續(xù)構(gòu)建，配合 F5 快捷鍵啟動調(diào)試

這些信息是后續(xù)分析源碼的必要條件，而這個過程跟學習一門新語言很類似，讀者可以回想一下最開始學習 JavaScript 的時候，有經(jīng)驗的學習者不會一上來馬上深入諸如原型、變量提升、事件循環(huán)等語言細節(jié)，而是先以更高層、更抽象的視角學習 JavaScript 語言的基本骨架，包括函數(shù)、循環(huán)語句、分支判斷語句、對象等，從而構(gòu)建起一個抽象的結(jié)構(gòu)化認知，后續(xù)再慢慢填充細節(jié)，有點自頂向下的味道。

設定切入點

在對項目背景與結(jié)構(gòu)有基本了解之后，我們可以正式開始分析源碼了。首先，讀者要找到一個匹配自身狀態(tài)和需求的切入點，本質(zhì)上就是將大目標拆解成一系列小目標，將大問題拆解成一系列更具體的小問題，然后帶著具體問題更聚焦地去看代碼。

所謂切入點可以直接對標到框架的具體功能，或者某些底層機制的實現(xiàn)上，以 Vetur 為例，它實現(xiàn)了諸多輔助開發(fā) Vue SFC 組件的特性，包括代碼補全、錯誤診斷、代碼高亮、跳轉(zhuǎn)到定義、hover 提示等等，這里面任意一個展開來都有大量可以挖掘的空間，如果從一開始就漫無目的瞎逛亂看那鐵定是看不出個所以然的，鑒于我的目標就是想通過 Vetur 學習 VS Code 插件的開發(fā)套路，所以選擇了一個看起來比較簡單的特性：代碼補全作為第一個切入點，后續(xù)的學習經(jīng)歷證明這是一個非常合適的點，不復雜但是已經(jīng)能幫我窺見 Vetur 的核心工作機制，以此類推后面分析其它高級特性如代碼高亮、代碼補全等，基本上就是很輕車熟路的狀態(tài)了。

如果你有一些更明確的目的，比如解決某個具體的 bug，那你應該會更容易 get 到當下最需要做的事情；如果始終抓不到要點，那么建議先回到前面“了解背景知識”或“理解項目結(jié)構(gòu)”的步驟，繼續(xù)探索一些上下文信息，再試試問自己：我接下來到底應該先了解哪些具體功能的實現(xiàn)邏輯？

記住，這并不是一錘子買賣，如果你在后續(xù)的分析過程中發(fā)現(xiàn)這個切入點變得越來越復雜，超出最開始的預期，不要有心理負擔，這再正常不過了，而且反而側(cè)面表現(xiàn)出你對問題域有越來越少的理解了，可以回過頭來重新調(diào)整目標，找一個更小的切入點。

善用搜索引擎

定下切入點后，首先要做的不是打開代碼咔咔就干，而應該首先試試在社區(qū)搜索相關(guān)的資料，畢竟自媒體時代了，很多開源框架的知識已經(jīng)被無數(shù)人吃透、捏碎、重組成各種維度的文章，順著這些文章的思路去理解源碼會比完全靠自己摸索效率高很多。

列舉幾種我常用的搜索渠道：

谷歌 and 百度一類的搜索引擎，體感上谷歌的搜索質(zhì)量會好很多，不過有一定的英語門檻
開源項目的官網(wǎng)、社區(qū)、wiki、github 等官方渠道，通常都會有比較不錯的資料
Segmentfault、知乎、掘金、公眾號等垂直社區(qū)
國外的 Medium/StackOverflow 社區(qū)，質(zhì)量極高，很多大佬在上面活躍

假如搜了一通找不到答案，可以試試不同的關(guān)鍵詞組合，我經(jīng)常用的關(guān)鍵詞有：

Xxx 源碼解析
Xxx 原理
如何實現(xiàn) xxx

假如還是找不到，還可以試試換一個意思接近的關(guān)鍵詞，繞點彎路。總之就是想盡辦法找到有用的，適合當下問題的信息，幫助讀者更快更平滑地深入研究源碼，這一步對新手尤為重要。

分析關(guān)鍵流程

前面說了一大通，到這里終于要開始正兒八經(jīng)地深入研究代碼了。

其實源碼分析的過程特別像偵探電影，最開始你需要面對一堆凌亂，看起來相關(guān)又不太相關(guān)的線索，偵探需要從這千頭萬緒中找出唯一事實答案，這個過程通常有兩種行之有效的做法，一是自頂向下，從時間線、流程的角度出發(fā)歸納出大致的事件框架，之后再深入研究細節(jié)，由抽象到具體；一是自底向上，找到疑點再往上逐層推敲，梳理出事件的全貌，由具體到抽象。

兩種方式各有適用場景，如果出于學習目的，就是想了解某些功能特性的實現(xiàn)原理的話，就應該自定向下，從應用入口出發(fā)逐步向下跟蹤梳理出執(zhí)行流程，理解大框架之后深挖具體細節(jié)；而如果是追查單一 bug 的時候就應該找到出問題的地方，自底向上追溯出全貌再加以更改。

我個人會更傾向于自頂向下的方式，例如我在學習 Vetur 的時候，首先是選定了代碼補全這一類功能作為切入點，之后從 server/main.ts 開始一路沿著主流程向下逐級探索，最終到達實際執(zhí)行代碼補全的位置，雖然實際學習過程沒有現(xiàn)在說的這么順利，但最終還是慢慢推導出了這樣一個流程圖：

這個流程圖非常重要，它基本上讓我理透 Vetur 的兩個重要階段：

啟動階段，vls 類型會初始化化 projectService 對象，之后再監(jiān)聽各類 LSP 事件
執(zhí)行階段，LSP 事件觸發(fā)時，vls 會將事件直接委托給 projectService 對象處理，而 projectService 會做兩件事情：

針對 SFC 文件做 region 切割，解析出 template、script、style 等區(qū)塊
針對不同區(qū)塊，調(diào)用 modes/xxx 對象的 doComplete 函數(shù)處理

基于這個流程圖，邏輯上可以推斷出：所有 LSP 請求最終都會按照代碼的類型流轉(zhuǎn)到相應的 **modes** 文件夾上，例如：

對于 template 的格式化請求，最終會流轉(zhuǎn)到 modes/template/index.ts 文件的 format 函數(shù)做處理
對于 style 的格式化請求，則流轉(zhuǎn)到 modes/style/index.ts 文件的 format 函數(shù)
同理可以推導出包括代碼補全、hover 提示、跳轉(zhuǎn)到定義、錯誤診斷等等高級特性上

這個發(fā)現(xiàn)讓整個 Vetur 的代碼架構(gòu)變得很扁平，后續(xù)研究具體特性的時候可以跳過前面這一對 LSP 請求的處理、分割步驟，直接找到對應的 modes/xxx/index.ts 代碼。

那么，如何分析代碼的執(zhí)行流程呢？我個人總結(jié)的方法有兩個：靜態(tài)猜想 + 動態(tài)驗證，放在下一節(jié)細講。

局部深入

經(jīng)歷前面一系列步驟，儲備了足夠的背景知識與框架認知后，我們可以開始逐行分析源碼，了解每一行、每一個變量、每一個函數(shù)、每一個模塊的具體作用與實現(xiàn)了。接下來我會介紹兩種行之有效的方法論：

靜態(tài)猜想：“讀”源碼，從面上理解代碼邏輯并作出猜想
動態(tài)驗證：“運行”源碼，借用 debug 工具逐行跟蹤代碼執(zhí)行過程，必要時可以改動原有代碼，驗證猜想

這兩種方法并不涇渭分明，通常是一邊看代碼，一邊做推測，有疑點馬上運行起來驗證猜想是否正確，靈活配合使用效果更佳。

靜態(tài)分析 —— 做猜想

所謂的靜態(tài)分析，說白了就是逐行逐句分析代碼，研究每一個變量、每一個過程的作用，是一個特別吃基礎知識和信息檢索能力的苦力活。雖然每個框架的實現(xiàn)細節(jié)不一樣，但還是有一些普適的技巧可以討論一下：

函數(shù)層面，關(guān)注輸入輸出及副作用：

函數(shù)接受什么結(jié)構(gòu)的參數(shù)，這些參數(shù)經(jīng)過函數(shù)內(nèi)部的每一條語句之后會發(fā)生什么變化，或者如何影響語句的執(zhí)行
函數(shù)執(zhí)行完畢之后，會返回什么結(jié)構(gòu)的結(jié)果，這些結(jié)果下一步會被誰消費，影響誰的執(zhí)行邏輯
特別的，有不少庫的函數(shù)實現(xiàn)有明顯的“副作用”，不是那么“純”，包括 Webpack、Vetur、Eslint 等 —— 這會急劇提升理解成本，所以閱讀的時候多留個心眼

分支語句中，優(yōu)先關(guān)注主流程，分支流程很容易增加心智負擔，到后面就不認得誰是誰了
對于循環(huán)語句，通常可以關(guān)注循環(huán)之前的狀態(tài)與之后的狀態(tài)，通過這些變化推斷循環(huán)的作用
對于變量與子函數(shù)，根據(jù)命名推斷作用，通常不必過度細究
跳過參數(shù)校驗、錯誤處理等分支邏輯，抓主流程！抓重點！
謹記你要研究的切入點，遇到特別復雜的子模塊，先大致理解功能，點到為止，記下這個硬骨頭回頭再作為一個新的切入點繼續(xù)研究
學點常用的設計模式，工廠、裝飾器、代理等等，這些模式的使用率非常高

結(jié)合這些技巧，在分析過程中讀者應該還是會遇到很多推測和問題：這個函數(shù)是干什么的；這個語句太復雜了，看不懂；這個循環(huán)太多 side effect 了，捋不出重點。有問題是好事，證明你開始能看出端倪了，這個時候就需要將框架運行起來，并且逐步、動態(tài)地觀察代碼的流轉(zhuǎn)，驗證你的猜想或者問題。

動態(tài)分析 —— 驗證猜想

經(jīng)歷前面靜態(tài)閱讀代碼后，相信讀者已經(jīng)有一些對代碼邏輯的基本推斷與問題，接下來就需要運行框架，在任何有疑問的地方添加斷點，觀察執(zhí)行棧、參數(shù)變化、環(huán)境變化、邏輯分支語句，確定輸入?yún)?shù)是如何確定的，輸出結(jié)果又會被誰消費。

不過，要修改、運行起一個開源框架可能并不容易，通常需要關(guān)注三個點：

如果框架已經(jīng)接入了一些工程化工具，需要弄清楚如何將源碼編譯為運行產(chǎn)物，例如 Vetur 項目接入了 tsc + rollup，對應的命令為 yarn watch/compile
如何啟動調(diào)試模式，例如 Vetur 場景下需要借用 VS Code 的 .vscode/launch.json 配置文件 + F5 命令啟動調(diào)試；而對于前端框架如 Vue、React，通常打開瀏覽器的 DevTool 面板即可
如何插入調(diào)試語句，前端或 Node 場景下通常添加 debugger; 語句即可

如果一段代碼你運行不起來，那么你大概率是無法掌握它的，所以我才會在前面“了解背景知識”一節(jié)特意強調(diào)需要了解項目的入口、啟動、調(diào)試方法，而一旦掌握了調(diào)試技能，那這份代碼在你面前就相當于脫掉了所有外裝，可以逐行、逐句觀察代碼邏輯的動態(tài)流轉(zhuǎn)。

及時總結(jié)

好記性永遠不如爛筆頭，前面花了這么多時間不斷探索、驗證，如果沒有及時做筆記，那這大概率會是一場無用功；而如果沒有及時做總結(jié)，那大概率無法將信息內(nèi)化為你腦子里面的知識！

當然了，也沒必要把這事看得太難，總結(jié)的目的是對已經(jīng)掌握的零碎信息做一次抽象，撇除部分細節(jié)，進而整合、梳理成體系化的知識，重點在于內(nèi)化成自己的知識而不是具體形式形態(tài)！所以不要完美注意，不要糾結(jié)把語句寫的更漂亮，把圖畫的更好看，在確保基本邏輯通順的前提下怎么快怎么來。

我個人的習慣是針對一個主題會單開一個自己可見的飛書文檔，閱讀過程不斷記筆記 —— 都是一些沒有任何修飾的大白話，一旦自我感覺到達一個節(jié)點就馬上做一次總結(jié)，將代碼流程歸類為 N 個步驟 —— 盡量控制在 10 個以內(nèi)，每個步驟寫清楚邏輯和輸出，條件允許的話還會同步畫一些粗糙的流程圖、時序圖、狀態(tài)機等。最后，攢到一定量級后我還會更進一步地，輸出對外的文章或 PPT，作為對自己學習成果的驗收。

下一個切入點

人類所知的物質(zhì)，或人類創(chuàng)造的產(chǎn)品中，沒有一樣是絕對簡單的，優(yōu)秀的開源項目通常是非常復雜的組合體，如果僅僅停留在“怎樣實現(xiàn)某個具體功能”，那遠還沒有掌握精髓，你還需要繼續(xù)探索，分析它“怎樣實現(xiàn)、組合多個單體功能”——但不是各自為政，互不相干的“多個”，而是互相融合成有機整體的“多個”。

所以在理解某個切面后，我們可以繼續(xù)沿用上面的分析步驟，循環(huán)敲定下一個切入點，可以是你之前遺留下來的復雜問題，或者某個新的功能特性，沿著這些碎片順藤摸瓜，逐步梳理成一套比較體系化的認知。

放在 Vetur 語境下，當時經(jīng)過第一遍分析之后我基本上就掌握了 Vetur 的架構(gòu)、核心流程及代碼補全的實現(xiàn)細節(jié)，了解到“所有 LSP 請求最終都會按照代碼的類型流轉(zhuǎn)到相應的 **modes** 文件夾上”這一基本規(guī)則。接下來我想繼續(xù)挖掘其它特性的實現(xiàn)原理，包括錯誤診斷、跳轉(zhuǎn)定義、智能提示等，于是重新設定切入點，重新跑一邊搜索、流程分析、局部深入，循環(huán)往復并最終總結(jié)出一系列知識點，匯總組織成在線分享：《如何開發(fā)一款 VS Code 語言插件 —— 以 Vetur 為例》，人生第一次直播。

最佳實踐

再聊聊我個人比較認可的最佳實踐吧：

設定好具體、可衡量的目標，不要為了學習而學習，如果有切實的強訴求，那就別由于彷徨，馬上去做
磨刀不誤砍柴工，不要上來就對著源碼瘋狂輸出，一定要花點時間站在高層視角去看框架的背景和生態(tài)
抓大放小，忽略哪些還不熟悉的概念、語句、工具、分支邏輯，你要認識到復雜事物的學習模型往往螺旋上升，逐步深入的，不可能過一遍就能掌握所有細節(jié)和精髓，如果一開始就過度關(guān)注細節(jié)，通常會讓整個學習周期拉到無限長。要弄清楚啥時候，什么情況下應該忽略細節(jié)，什么時候應該抓住不放 —— 這與你的目標和切入點有很大的關(guān)系
隨時筆記：一旦有任何新發(fā)現(xiàn)、新問題，做好筆記，記錄下來，這些都會成為繼續(xù)探索的重要線索
隨時總結(jié)：

筆記記錄當下的、零碎的發(fā)現(xiàn)，總結(jié)則將這些線索串聯(lián)形成知識點。
總結(jié)過程你會發(fā)現(xiàn)更多認知漏洞，提出更多問題，可以反過來繼續(xù)挖掘
好記性不如爛筆頭，探索的結(jié)果落到紙面上才會真正成為你自己的東西，極端一點看，沒有形成輸出的學習過程往往會隨著時間的流逝，變成徒勞

學習畢竟很個人的事情，上面提到的這些方法、技巧、原則對我個人特別受用但實際效果必然還是因人而異的，如果讀者執(zhí)行過程中感覺特別膈應特別難受，那完全可以適當微調(diào)，慢慢找出更適合自己的方式方法。

點擊左下角閱讀原文，到 SegmentFault 思否社區(qū) 和文章作者展開更多互動和交流，掃描下方”二維碼“或在“公眾號后臺“回復“ 入群 ”即可加入我們的技術(shù)交流群，收獲更多的技術(shù)文章~

- END -

如何閱讀源碼 —— 以 Vetur 為例

弄清楚目標

閱讀技巧

了解背景知識

六步循環(huán)分析

理解項目結(jié)構(gòu)

入口分析

探索 contributes.languages 配置

探索 contributes.grammars 配置

探索 main 配置

小結(jié)

基礎依賴分析

文件結(jié)構(gòu)

小結(jié)

設定切入點

善用搜索引擎

分析關(guān)鍵流程

局部深入

靜態(tài)分析 —— 做猜想

動態(tài)分析 —— 驗證猜想

及時總結(jié)

下一個切入點

最佳實踐