问题驱动——不要为了看源码而看源码

是带着问题去看源码,比如想了解一下 React 的合成事件系统的原理,想了解 React 的 setState 前后发生了什么,或者想了解 Webpack 插件系统的原理。也有可能是遇到了一个 bug,怀疑是框架/工具的问题。在这样的情况下,带着一个具体的目标去看源码,就会有的放矢。

看最新版的源码

基本了解

看源码之前需要对项目的原理有一个基本的了解。所谓原理就是,这个项目有哪些组成部分,为了达到最终的产出,要经过哪几步流程。这些流程里,业界主流的方案有哪几种。

那我们要如何了解这些呢?要了解这些,可以去各大网站和博客上的《XXX源码解析》系列。通过这些文章,我们可以对我们要看的框架/工具的原理有一个大致的了解。

本地build

看源码的第一步就是把项目的代码仓库 clone 到本地。然后按项目 README 上的构建指南,在本地 build 一下。

大型的开源项目一般都会有一个 Contribution Guide,目的是让想贡献代码的开发者更快上手。里面就有讲怎么在本地构建代码。

理清目录结构

在看具体的代码之前,我们需要理清项目的目录结构,这样我们才能更快的知道在哪里地方找相关功能的代码。

如果这个项目是一个 monorepo,首先我们要找到核心的那个 package,然后看里面的代码。

不是 monorepo 的话,一般来说,如果这个项目是一个 CLI 的工具,那 bin 目录下放的就是命令行界面相关的入口文件,lib 或者 src 下面就是工具的核心代码。如果这个项目是一个前端 View 层框架,那目录结构就和 Vue 类似。

debugger && 全局搜索大法

运行了本地的 build,了解了目录结构,接下来我们就可以开始看源码了。

在对应的地方打一个断点,然后运行本地的 demo 页面,就可以在 Devtool 里看到断点了。

我们在熟悉框架的原理之后,就可以在框架的关键链路上打断点,比如前端 View 层框架的声明周期钩子和 render 方法,Node 工具的插件函数,这些代码都是框架运行的必经之地,是不错的切入点。

原文地址