如何阅读JS源码？读源码有什么好处

这几天在公司接手了一个项目，是之前其它组的，现在要继续完成它。那我要做的第一件事，就是熟悉代码。对，就是看别人写的JS代码。文档嘛，自然是没有的。

之前也有试过看代码，但项目中N多JS文件，每个JS文件上千行，一行一行的看下来，用不了几分钟就完全晕掉了。完全不知道某一行里的判断，是在判断什么，那个变量是什么意思，顺着调用顺序看下来，会发现看到后面的时候，前面看的内容已经忘了。

于是，这一次，我决定换一个方式读JS源码。

这个项目中有N个JS文件，我把入口的JS文件拿出来先看，然后我把它里面所有的函数名，都用思维导图写出来，就像这样，

在这样做的时候，只是看看函数名在做什么，不去读函数内部的细节。我觉得这种方法会比较适合这种上百个JS文件，每个文件至少一千行以上的复杂项目。

这样做的好处首先就是从文件和函数上理解项目的结构。凡是大型的JS项目，必然会有基类，继承，那么我们要先找到它的根类，然后从它开始阅读，这就是自上而下的方式。并且要写笔记，如果能用UML或思维导图那就更好了。这样可以用图形来描述这些函数或是对象，它们之间是如何连接在一起的。就像这样，

要明白，阅读源码不可能只读一遍就看明白，它不是小说。还要切记，阅读源码时，在前几遍不要太深入阅读函数的具体内部实现，而是要从全局、结构、宏观上去明确它们之间的关系。例如，A调用了B，返回了C，OK，你已经知道了ABC三者之间的关系，但它们内部是如何实现的，先不要管。否则很容易迷失在具体的代码中。

通过画图来把ABC以及更多的对象、方法、全局变量和它们的关系都画出来之后，你会发现它们中有一些是起到联络、中转的作用，那么可以把它们当做一个十字路口，进而找到红绿灯。当你找在程序中找到几个这样的路口和红绿灯之后，你应付发现，对于项目程序的主干、支流会慢慢的理清。再次强调，不要在头一二次阅读源码的时候就直接研究函数内部的实现细节。

如果代码是可以另存在你本机运行的，你可以边调试边阅读，用debug和console.log，还有你自己的特有的注释。这也是阅读源码的笔记。在阅读的时候如果遇到好的写法、流程、架构，必须要用本子记下来，就像写文章一样，都是有格式的。

在阅读代码的时候，要注意控制阅读代码的层级。就是说，大函数里，有中函数，中函数里又有小函数，小函数里有具体的实现细节。那么我们阅读的时候，最多只到中函数，就不再往内部再看了。因为再深入就会纠结于具体的实现细节，这在初期阅读源码时没什么好处。

在看代码的阶段中，至少会有三个阶段，了解，修改，提炼。虽然看小说和看源码，都是用读的。但区别在于，小说是给人看的，所以是从人的易于理解角度去编写，但程序是写给机器看的，所以是从机器易于理解的角度去写。

看小说一行行看就OK，但读源码的重点，不在于要读完并理解每一行JS代码，而在于通过图表和笔记，理解系统的结构和它们之间的关系。当你需要在某一个模块中进行修改，或添加新功能模块的时候，能够快速的脑子里找到项目中正确的代码位置。这时才是仔细看代码内部细节实现的时候。

而且我个人认为，开发的时候，时间紧任务重，让你熟悉代码，并不是让你通读每一行代码。实际上这也是不可能的，每个大项目中上百个JS文件，每个JS文件上千行、几千行代码，这算起来就十万多行了，哪有时间让你慢慢看完。

推广来说，看项目源码，看前端各种构架的源码，它最大的好处就是可以培养自己的对于代码的“层次感”。前端讲究架构，有架就要有层，不同的架构有不同的层次，不同的层次对应不同的角色，这些角色之间的关系，和它们相对于整个架构的位置，它们互相之间的互动模式，，，多看源码，有方法有技巧的多看源码，能够让我们理解整个系统的运行逻辑。

看到这里，不知你明白没有，这就是“前端架构师”的工作，也就是我现在在做的工作。