目前网上有很多诸如《XX源码分析》之类的文章，但这类源码分析的文章范围有限，有时内容并不是读者最关心的。 同时，我也注意到源代码在不断更新，文章中写的源代码经常是过时的。 因为这种问题，很多朋友喜欢自己看源码，自己动手webpack里面babel，丰衣足食。
本文主要讲一下阅读React、Vue、Webpack、Babel等小型后端开源项目源码时的一些方法。 目的是为了让你在遇到需要通过阅读源码来解决的问题时，更快的定位到你想看的代码。 授人以鱼不如授人以渔。 希望大家通过这篇博客能够了解到阅读后端小型项目源码时的切入点。 以后遇到好奇的问题，可以自己去探索。
问题驱动——不要仅仅为了看源代码而看源代码
首先我们要明确，看源码的目的是什么？
我个人的看法是看源码就是解决问题的。 开源项目的源代码没有什么特别之处，都是通用的代码。 这些代码的数量级通常相当大。 如果你想从源码中学习一些东西，直接浏览整个Codebase无疑是大海捞针。
但如果你带着疑问去看源码，比如你想了解React的合成风暴系统原理，React的setState前后发生了什么，或者Webpack插件系统的原理。 也有可能遇到了bug，怀疑是框架/工具的问题。 这种情况下，看源码就会有的放矢。
查看最新版本的源码
之前看到一句话，看源码，应该从项目的第一次commit开始。 如果是为了解决上一篇中框架/工具带来的困扰，自然就取决于当前项目所使用的框架/工具的版本。
如果是学习源码的话，我也建议看最新的源码。 因为一个项目是不断迭代和构建的。 版本之间可能会有完整的重绘。 比如Vue 2.x和React 16。重构导致了代码结构的一些变化。 Vue 2.x 引入了 Virtual DOM，Pull + Push 的数据变化测量方式让整个代码的结构更加清晰，所以虽然 2.x 的代码比 1.x 更容易阅读。 React 16 重写了 Reconciler 并引入了 Fiber 的概念。 整个代码仓库的结构也比较清晰，推荐阅读。
前提条件
怎么看源码，当然不能穿梭了。
在看源码之前，需要对项目的原理有一个基本的了解。 所谓原则就是，这个项目由哪些部分组成，必须遵循哪些步骤才能达到最终的输出。 在这些流程中，业界主流的解决方案有哪些？
比如后端View层框架，要渲染UI，组件要经过挂载、渲染等步骤。 数据驱动的后端框架，挂载后会进入一个循环，当用户交互触发组件数据变化时，UI就会更新。 其中，数据的计量方式分为两种方案：Push和Pull。 渲染UI可以是全字符串模板替换，也可以是基于Virtual DOM的差异化DOM更新。
再比如一些后端工具，比如Webpack、Babel等，都是基于插件的。 基本工作流程是读取文件，将代码解析为AST，调用插件转换AST，最后生成代码。 要理解Webpack的原理，你需要知道Webpack是基于一个名为tapable的模块系统。
那么我们如何理解这一点呢？ 要了解这一点，可以去各大网站和博客上的《XXX源代码分析》系列。 通过这种文章，我们可以对我们想要看的框架/工具的原理有一个大概的了解。
本地构建
但最终我们还是要直接看源码。 笔者真正看源码的第一步就是将项目的代码仓库clone到本地。 然后根据项目README上的构建手册在本地构建。
如果是后端框架，我们可以直接将本地构建的umd包导入到HTML中（记得使用开发构建，否则代码会被压缩，可读性很差），然后写一个简单的demo，它导入本地构建。 如果是基于Nodejs的工具，我们可以使用npm link将该工具的命令链接到本地。 也可以直接看项目的package.json的入口文件，直接用node运行哪个文件。
这里需要指出的是，大型开源项目通常都会有一份贡献指南，其目的是为了让想要贡献代码的开发者能够更快上手。 有关于如何在本地构建代码的说明。
以React为例，React的贡献指南中有一个名为“开发工作流程”的部分。 里面有这样一段话：
尝试更改的最简单方法是运行yarn build core,dom --type=UMD，然后打开fixtures/packaging/babel-standalone/dev.html。 该文件已经使用了构建文件夹中的react.development.js，因此它将获取您的更改。
因此React存储库中的fixtures/packaging/babel-standalone/dev.html是一个方便的演示页面。 我们可以在此页面快速查看我们本地对代码的修改。
你可以尝试在项目的入口文件中添加一条日志，看看在控制台/终端中能否听到这条日志。 如果可以的话，恭喜你，你现在可以自由地玩这个项目了！
清理目录结构
在看具体代码之前，我们需要先明确一下项目的目录结构，这样我们才能更快的知道在哪里可以找到相关功能的代码。
我们来看看React的目录结构。 React 是一个单一仓库。 即一个仓库包含多个子仓库。 我们可以在packages目录中看到很多单独的包：
React 16之后，React的代码分为三部分：React Core、Renderer和Reconciler。 这是因为React的设计允许我们将负责将数据映射到UI的Reconciler和负责将Virtual DOM渲染到各个终端的Renderer从React Core中分离出来。 React Core 包含 React 的类定义和一些顶级的 API。 渲染和View层差异的大部分逻辑都在Reconciler和Renderer中。
Babel 也是一个单一存储库。 Babel 的核心代码是 babel-core 包。 Babel 开辟了一个套接字，允许我们自定义 Visitor，在 AST 转换时调用。 所以 Babel 的仓库中也包含了很多插件，虽然真正实现句子转换的是那些插件，而不是 babel-core 本身。
Vuejs的代码比较典型，核心代码在src目录下，由功能模块定义。 因为Vue也支持多平台渲染，所有平台相关的代码都放在platform文件夹中，core文件夹是Vue的核心代码，编译器是Vue的模板编译器，它将HTML风格的模板编译成渲染函数。
Webpack 和 Babel 一样，可以说是一个基于插件的系统。 Webpack的主要源码在lib目录下，里面的webpack.js是入口文件。
上面提到了四个项目的目录结构，那么当我们遇到一个新的开源项目时，我们应该如何理解它的目录结构呢？
如果这个项目是monorepo，首先我们需要找到核心包，然后看上面的代码。
如果不是monorepo，一般来说webpack里面babel，如果项目是CLI工具，则与命令行界面相关的入口文件放在bin目录下，工具的核心代码放在lib或src下。 如果这个项目是后端View层框架，那么目录结构和Vue类似。
作为验证，可以查看打包工具parcel和后端View图层库moon的目录结构。 目录结构往往都是类似的，多看几个项目就会熟悉了。
调试器&&全局搜索方法
运行本地构建并了解目录结构后，我们就可以开始查看源代码了！ 正如我之前所说，我们需要由问题驱动。 接下来我将以React调用setState前后发生的问题作为反例。
我们可以在 setState 所在的位置下一个断点。 首先我们需要找出setState在哪里。 这时候，之前的策划工作就派上用场了。 我们知道React的公共API是在react包下的。 我们在哪个包中全局搜索。 我们发现这个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构建的demo页面，让组件触发setState，我们就可以在Devtool中看到断点了。
当我们接近this.updater.enqueueSetState的调用时，我们来到ReactFiberClassComponent函数中的enqueueSetState，这里调用了enqueueUpdate和scheduleWork两个函数。 如果我们想深入setState之后的流程，只需要点击
走进这两个函数就可以看到具体的代码了。
如果我们想查看setState之前发生了什么，只需要查看Devtool右侧的调用堆栈即可：
单击每一帧可跳转到相应的功能并恢复当前上下文。
结合一步一步的代码调试，我们可以看到框架的函数调用栈。 对于每一个重要的功能，我们都可以在仓库中搜索源码进行进一步的研究。
Node工具的调试方法也类似，我们可以在运行node命令时添加--inspect参数。 有关详细信息，请参阅使用 Chrome DevTools 调试 Node.js。
其实单步调试的这些方法大家都知道，但是断点是最关键的。 当我们熟悉了框架的原理之后，我们就可以在框架的关键环节上进行断点，比如后端View层框架的声明循环钩子和render方法，以及Node工具的插件功能。 这些代码是框架运行所必需的。 这是一个很好的切入点。
如果是为了了解一个具体的问题，可以直接从你认为有问题的点上突破。 然后运行源码，想办法让代码运行在哪里。 我们可以在断点处看到局部变量等信息，有助于定位问题。
来自开发团队的资源
事实上，开源项目的开发团队也致力于让更多的人参与到项目中，降低项目的门槛。 所以我们可以在网上找到开发团队的很多资源。 这些资源可以帮助我们理解项目的原理。
