编程语言
首页 > 编程语言> > 想读项目源码？可为什么总是读不下去？

想读项目源码？可为什么总是读不下去？

作者：互联网

本篇是专题《如何高效阅读源码》的第一篇，来聊一聊阅读源码的错误姿势！以及本专题的内容及章节。

似曾相识的场景

你听说Spring已经有一段时间了，它已经是Java企业级开发事实上的标准。你觉得自己应该读一读Spring的源码，深入理解一下Spring的实现，这能使自己更好的使用Spring，同时也能提高自己项目设计和编码能力。

于是你泡了一杯咖啡，从github上下载最新的Spring源码，导入到IDE中，写了一个demo，然后就开始debug。你一边StepOver，一边嘴里嘟囔着「A类的a方法调用了B类的b方法，然后又调用了C类的c方法，然后又执行到了这里」。嗯，很清晰嘛，喝口咖啡。咦，刚才看到哪里了？！没办法，只好重新debug！

「A类的a方法调用了B类的b方法，然后又调用了C类的c方法。。。。。。这里是个接口，要执行的是子类，子类在哪里呢」？你在IDEA里按下ALT+F7，发现有几十个实现，到底是哪个实现呢？你按下F7 StepIn想确认下。我去，一堆AOP的包装方法，按了半天，就是进不到最终的类！

最后，好不容易找到了执行的类。咦，刚才看的是什么来着？！唉，算了，看不下去了，先来把王者吧！然后，就没有然后了！！！
为什么你没办法把源码读下去呢？因为你的方法不对：

我们一个个的来说！

不了解项目就读源码

首先，你了解项目了吗？你有实际使用过项目吗？你对项目的执行流程了解多少？如果你还没有熟练的使用项目，那你就不要急着去读项目源码。
读源码需要在熟练使用的基础上进行。为什么呢？

你想想你读源码的目的是什么？你是希望能了解这个项目是如何设计实现的，代码如何组织的，有哪些技巧或思路可以学习。但是你连项目都不了解，你怎么去理解这个项目是怎么设计的？

就像上面，你只知道Spring是目前企业级开发事实上的标准，但是你不知道原因，也不知道它解决了什么问题，以及解决问题的方式。那你如何能理解代码为什么要这么写？！假如你最终千辛万苦的终于将Spring源码读完了，你也只知道Spring构建了Bean塞到了容器中，然后使用的时候获取这个Bean，而不清楚深层次的用意。

一上来就读最新版本的源码

很多开源项目经历了很多年，代码量成指数级增长。版本越新，代码量也就越多。以Spring来说，现在Spring已经到了5.*版本，从git上下载下来的spring-framework的源码大小有200多兆，你能想象这得有多少代码吗？一上来就读这种庞然大物，心里不瘆得慌才怪！

所以从相对老一点的版本入手，代码量上会少很多，阅读起来也会容易很多。但是版本也不能太老，太老的版本可能使用的技术已经过时了，读了也没有什么太大的用处。

直接看完整代码

虽然老版本的代码量相对少一点，但是一个相对较大一点的项目的代码量还是比较多的。比如Spring3的代码量也已经很多了。
所以，无论是哪个版本的源码，你都不应该看完整的代码。那该怎么去读源码呢？这就是本专题要解决的问题之一，在后面的章节中会进行详细的讲解。

通过debug的方式阅读源码

很多源码分析的博客都是通过debug的方式来讲述源码。也有不少教读源码的文章，也是建议通过debug的方式来进行阅读。但是，实际上通过debug的方式来阅读源码不是一个好方法，至少一上来就进行debug，是个很不好的习惯。

大部分人应该都知道，人的记忆可以分为「短时记忆」和「长时记忆」！对于「短时记忆」来说，一般正常人一次只能记忆7（加减2）个左右的无规律信息。对于通过debug进行源码阅读的方式，每一次的方法跟进，实际就是一次信息记忆，所以最多7次左右的StepOver，你就没法记住所有的调用关系了。所以你就会出现看了后面忘了前面的情况。

同时像Spring这种使用了AOP的项目，由于在运行时有多层的代理，所以debug的层级更多，也就更加的难以阅读了。
再加上众多的子类实现，很容易就迷失在了一堆没用的代码中。

专题内容

既然已经知道了错误的阅读源码的方式，那正确的阅读源码的方式是什么呢？这就是本专题的内容！
本专题包括四部分内容：

看完本专题，你将学会：

预备知识

为了更好的理解本专题，你最好需要：

适用人群

标签：想读,项目,Spring,源码,阅读,debug,总是,本专题
来源： https://www.cnblogs.com/ivaneye/p/15911934.html