责任编辑主要撷取写作大型后端开放源码比如说：React、Vue、Webpack、Babel源标识符的许多基本功。目的是让他们在碰到需要写作源标识符才能化解的难题时，能快速功能定位到自己想看的标识符。
一、为甚么看源标识符？
首先，我们要明确的是，看源标识符的目前第是甚么。
异军突起意见，看源标识符是为介绍决难题。开放源码工程项目的源标识符好是好，但标识符的量级巨大，想从源标识符中自学东西，直接下载整个Codbase，实在是Reston。
但假如带着难题看源标识符，比如说介绍一下React的制备事件控制系统的基本上原理，想介绍React的setState其间发生了甚么，或者想介绍webpack应用程序控制系统的基本上原理。也可能将是碰到了两个bug，揣测是架构/辅助工具的难题。在这样的情况下，带着两个具体的目标去看源标识符，就会随心所欲很多。
二、看正式版的源标识符
网路上好些人说，看源标识符要从工程项目的第两个commit已经开始看，假如是为介绍决前该文对架构/辅助工具产生的疑惑，那自然是要看当前工程项目中加进的架构/辅助工具版。
假如是为的是自学源标识符，这里也建议他们看新一代的。因为两个工程项目是在不断插值和解构的。不同版之间可能将是一次完全的改写。
三、怎样已经开始看源标识符
看源标识符之前要对工程项目的基本上原理有两个基本上的介绍，所谓的基本上原理是，这个项目有甚么样部分组成，为的是达到最终的工业生产，要历经那一百米业务流程。那些业务流程里，业内非主流的计划有这三类。
比如说后端 View 层架构，要图形出 UI，组件要历经 mount、 render 等等关键步骤。统计数据驱动力的后端架构，在 mounted 之后，就会进入两个循环式，当使用者可视化促发组件统计数据变化时，会预览 UI。其中统计数据的检验方式又有分 Push 和 Pull 两种计划。图形 UI 能是HMPP的数组模版代替，也能是如前所述 Virtual DOM 的差量 DOM 预览。
又比如说后端的许多辅助工具，Webpack 和 Babel 那些辅助工具都是如前所述应用程序的。基本上的工作业务流程是加载文档，导出标识符成 AST，初始化应用程序去切换 AST，最后聚合标识符。要介绍 Webpack 的基本上原理，就要知道 Webpack 如前所述两个叫 tapable 的组件控制系统。
那他们要怎样介绍那些呢？要介绍那些，能去数十家中文网站和网志上的《XXX源标识符导出》系列产品。通过那些文章，他们能对他们要看的架构/辅助工具的基本上原理有两个大致的介绍。
本地build不过最终他们还是要直接看源标识符。笔者真正看源标识符的第一步是把工程项目的标识符仓库 clone 到本地。然后按工程项目 README 上的构建指南，在本地 build 一下。
假如是后端架构，他们能在 HTML 中里直接引入本地 build 出的 umd bundle（记得用 development build，不然会把标识符压缩，可读性差），然后写两个简单的 demo，demo 里引入本地的 build。假如是如前所述 Nodejs 的辅助工具，他们能用 npm link 把这个辅助工具的命令 link 到本地。也能直接看工程项目的 package.json 的入口文档，直接用 node 运行那个文档。
这里要强调一下，大型的开放源码工程项目一般都会有两个 Contribution Guide，目的是让想贡献标识符的开发者更快上手。里面就有讲怎么在本地构建标识符。
以 React 为例，React 的 Contributing Guide 里就 Development Workflow 这一节。里面有这么一段话：
The easiest way to try your changes is to run yarn build core,dom type=UMD and then open fixtures/packaging/babel-standalone/dev.html. This file already uses react.development.js from the build folder so it will pick up your changes.
所以 React 仓库中的 fixtures/packaging/babel-standalone/dev.html 是两个方便的 demo 页。他们能在这个页面快速查看他们在本地对标识符的改动。
你能尝试着在工程项目的入口文档中加入一句 log，看看是不是能在控制台/终端看到这句 log。假如能的话，恭喜你，你现在能随便把玩这个工程项目了！
四、清理目录结构
在看具体的标识符之前，他们需要理清工程项目的目录结构，这样他们才能更快的知道在哪里地方找相关功能的标识符。
他们看看 React 的目录结构。React 是两个 monorepo。也是两个仓库里包含了多个子仓库。他们在 packages 目录下能看到很多单独的 package：
在 React 16之后，React 的标识符分为 React Core，Renderer 和 Reconciler 三部分。这是因为 React 的设计让他们能把负责映射统计数据到 UI 的 Reconciler 以及负责图形 Vritual DOM 到各个终端的 Renderer 和 React Core 分开。React Core 包含了 React 的类定义和许多顶级 API。大部分的图形和 View 层 diff 的逻辑都在 Reconciler 和 Renderer 中。
Babel 也是两个 monorepo。Babel 的核心标识符是 babel-core 这个 package，Babel 开放了接口，让他们能自定义 Visitor，在AST切换时被初始化。所以 Babel 的仓库中还包括了很多应用程序，真正实现语法切换的其实是那些应用程序，而不是 babel-core 本身。
Vuejs 的标识符比较典型，核心标识符在 src 目录下，按功能组件划分。因为 Vue 也支持多平台图形，所以把平台相关的标识符都放到了 platform 文档夹下，core 文档夹中是 Vue 的核心标识符，compiler 是 Vue 的模版编译器，把 HTML 风格的模版编译为 render function。
Webpack 和 Babel 一样，能说都是如前所述应用程序的控制系统。Webpack 的主要源标识符在 lib 目录下，里面的 webpack.js 是入口文档。
上面说了四个工程项目的目录结构，那他们碰到两个新的开放源码工程项目，应该怎么介绍它的目录结构呢？
假如这个工程项目是两个 monorepo，首先他们要找到核心的那个 package，然后看里面的标识符。
不是 monorepo 的话，一般来说，假如这个工程项目是两个 CLI 的辅助工具，那 bin 目录下放的就是命令行界面相关的入口文档，lib 或者 src 下面是辅助工具的核心标识符。假如这个工程项目是两个后端 View 层架构，那目录结构就和 Vue 类似。
作为验证，他们能看一下打包辅助工具 parcel 和后端 View 层库 moon 的目录结构。目录结构这个东西往往是大同小异，多看几个工程项目就熟悉了。
debugger &&全局搜索大法运行了本地的 build，介绍了目录结构，接下来他们就能已经开始看源标识符了！之前说了，他们要以难题驱动力，下面我就以 React 初始化 setState 其间发生了甚么这个难题作为例子。
他们能在 setState 的地方打两个断点。首先他们要找到 setState 在甚么地方。这个时候之前的准备工作就派上用处了。他们知道 React 的共有 API 在 react 这个 package 下面。他们就在那个 package 里面全局搜索。他们发现这个 API 定义在 src/ReactBaseClasses.js 这个文档里。
于是他们就在这里打两个断点：
Component.prototype.setState = function(partialState, callback){ invariant( typeof partialState ===object typeof partialState ===function partialState == null,setState(…): takes an object of state variables to update or a + function which returns an object of state variables.,); debugger; this.updater.enqueueSetState(this, partialState, callback,setState);};
然后运行本地 React build 的 demo 页面，让组件促发 setState，他们就能在 Devtool 里看到断点了。
他们走进 this.updater.enqueueSetState 这个初始化，就来到了 ReactFiberClassComponent 这个函数中的 enqueueSetState，这里初始化了 enqueueUpdate 和 scheduleWork 两个函数，假如要深入 setState 之后的业务流程，他们只需要再点击走进这两个函数里看具体的标识符就能了。
假如想看 setState 之前发生了甚么，他们只需要看 Devtool 右边的初始化栈：
点击每两个 frame 就能跳到对应的函数中，并且恢复当时的上下文。
结合一步一步的标识符调试，他们能看到架构的函数初始化栈。对于每个重要的函数，他们能在仓库里搜索到源标识符，进一步研究。
Node 辅助工具的调试方法也是相似的，他们能在运行 node 命令时加上 inspect 参数。
其实他们都知道单步调试这种办法，但在哪里打断点才是最关键的。他们在熟悉架构的基本上原理之后，就能在架构的关键链路上打断点，比如说后端 View 层架构的声明周期钩子和 render 方法，Node 辅助工具的应用程序函数，那些标识符都是架构运行的必经之地，是不错的切入点。
假如是为的是介绍两个特定的难题，他们能直接在自己觉得有难题的地方打断点。然后把源标识符运行起来，想办法让标识符运行到那个地方。他们在断点能看到局部变量等等信息，有助于功能定位难题。
五、善用辅助工具
Octotree，下载器扩展，在github上面显示标识符树，对你介绍整个工程项目结构有着非常大的帮助webstorm，这个看个人喜好吧，笔者比较喜欢WS，主要是里面的辅助工具比较全面，比如说支持typescript、babel等等许多后端经常加进的辅助工具SourceTree，git可视化客户端辅助工具，假如你喜欢从第两个commit已经开始看，那么这个辅助工具对你比较有帮助，看看快速介绍到每个版提交的内容以及源标识符变更记录，笔者以前比较喜欢用这个，但后面WS有自带的可视化辅助工具之后就没用过了。
