标签: 源码学习方法

我们为什么要看源码?

这个小标题好像有点扯淡,不过我感觉还是有必要聊一聊。
最近搞 Blazor,手边常备 AspNetCore 源码,遇到问题了就翻源码。
然后有同样关注 Blazor 的同学会一起讨论一些问题,我知道的问题会直接分享,我不知道的问题,我就,甩一句,“看源码”
然后有的同学炸了,说,“不是每个人都可以像你一样看源码,源码不是每个人都能看的,不是每个人都想看源码”
当然原话不是这样,后两句是我添油加醋的,不过这两句想必是大部分同学的心声,心里害怕看源码,觉得看源码都是大神才会看的。

看源码的正确姿势
st=>start: 遇到问题 search=>operation: 百度谷歌 isOk=>condition: 能解决吗?
donotusecode=>end: 好了你可以不用继续看了 usecode=>end: 分析源码解决 st->search->isOk
isOk(yes)->donotusecode isOk(no)->usecode
看源码的错误姿势
st=>start: 听说看源码能学到很多东西,能通过面试,能XXXXX usecode=>end: 看源码 st->usecode
感觉第二个流程图像是在扯犊子,其实第二个图也并非完全错误,只是在强调你不能为了看而看,你要带着问题去看,但如果这样的话,那其实又变成了第一张流程图了

看源码的方法

很多同学在满足第一个流程图的条件之后,可能看源码仍然感觉累,没有头绪,这是没掌握看源码的技巧,可能存在以下几种情况

* 拿着 github 在线看源码,这和拿记事本看源码没好到哪去
* 真的就拿着记事本看源码,或者拿着 VSCode 看源码(我不是黑它)
* 不擅于使用 VS 的相关功能
看源码一定先编译源码

不用编译直接打开 VS 一把梭,不是很好吗?
不好,确实是可以打开的,但是这个时候往往因为没有编译过导致 VS 的很多功能不可用,例如转到定义、查找引用。
对我而言,编译源码是个艰难的过程,看源码反而简单。特别是 AspNetCore 的源码,编译起来要了半条命。
关于怎么编译,每个开源项目都不一样,有的项目简单,打开 VS 直接就能编译,但是像 AspNetCore
这种,必须严格按照官方给的编译步骤文档,还得保证网络畅通,编译过程中很容易被劝退。

五大板斧不可少

有很多同学看源码的过程让我比较着急,咋看的呢?
CTRL+F,输入搜索词,全解决方案搜索,不管是怎样的情况全是这样搞,解决方案比较大的话一搜一大堆出来。
也许只是我周围的同学是这样的吧。
我看源码的过程中常使用这些方法

* 转到定义,F12
* 转到实现,CTRL + F12
* 查找引用
* 调用堆栈
* 解决方案管理器搜索
这五大板斧中,除了调用堆栈,其他的几乎都是静态分析代码的必备方法,调用堆栈一般属于动态分析代码的办法。
这五大板斧用好了,只要源码的变量命名不要太坑爹,基本上是不需要看注释的,我看开源项目的源码从来不看注释,开源项目的源码的命名一般都是比较好的。

下面我将举例来分享我看源码的过程,把上面这几个方法用上

问题实例:怎么根据路由获取对应的组件?

这是我在编写 BlazAdmin
时遇到的问题,我需要根据当前路由得到这个路由对应的那个组件,然后做一些操作,我甚至不知道如何搜索,因为关键词不好搞,随便搜了几个也没找到答案。

下面开始分享我针对这个问题的解决思路,下载编译 AspNetCore 源码的步骤我就不写了

第一个问题,从哪儿开始?

万事开头难,刚开始看源码更难,无头苍蝇的感觉。
我们的需求是,怎么根据路由获取对应的组件,这里面有两个关键词,一个是路由,一个是组件
我们换位思考一下,假如由我们来开发这个功能,我们会写哪两个类?
答案应当很明显,Router 和 Component,当然也许不是这么命名的,都有可能。但好像知道这两个名字了还是没啥用?根本问题在于
AspNetCore 解决方案太多,我们压根不知道应该打开哪个解决方案,也就无从搜索这两个类名。
我的办法是,也许这两个类我们是可以直接使用的,那么如果可以直接用的话,我们应该可以在代码的任意地方调用这两个类,那么我们就试试。
在我们自己项目的 Program.cs 文件中,随便找个地方,我们首先尝试 Router 关键字。



好像有戏,我们已经看到命名空间了,那么根据这个命名空间,我们尝试找到对应的解决方案,这个命名空间的关键词是什么呢?Microsoft?AspNetCore?这两个关键词太大众化了,那么只剩下两个,Components
和 Routing,我们一个一个来




没啥好说的,既然找到了,管它是不是,先打开看看再说。



我们直接在解决方案管理器中搜索这 Router 这个类。



我们的入口点已经显而易见了



第二个问题,这个类是如何找到 Component 的?

这个类中有这么些方法



根据方法猜功能,没错,看源码全靠猜,猜错了换条路继续

OnAfterRenderAsync 这个应该不是
OnLocationChanged 这里面都有些啥?



这里面调用了 Refresh 方法,F12 跟进去



开始发晕了,咋这么多呢,而且还不明显,我们一行行看,一行行猜
看第五第六行,这两行有点意思,跟当前路由有关,也许是我们想要的
F12 进 RouteContext,看看里面有啥



好吧啥也没有,我们继续看第六行,F12 进 Route 方法



越来越像了,Match 方法里面又是什么呢?F12 进去



这个方法中看起来也不像那么回事,不过还是有点有用信息,最后一句代码将 Handler 赋值了一下,但问题是 Handler
是啥?看这命名有点像当前路由的处理器,那么这个处理器可能就是我们要找的 Component,从构造方法中可以看出这个 Handler
是由构造方法传过来的,构造方法可以看到还有一个引用,意味着有地方在显示调用,那么我们通过查找引用跳过去看看



看来这就是我们要找的了,越来越近了,这里应该是在分析路由模板,那么路由模板应该是调用这个方法的地方传过来的,再次查找引用跳过去



两个地方在调,咋办?明显可以看出第一个地方是单元测试调的,所以其实只有第二个地方在调



Template 就是路由的模板,而这个模板是由 RouteAttribute 特性来得到的,而这个特性是标记在每一个组件的 Type
上的,也就是说,只要获取所有组件的 Type,就可以拿到所有组件对应的路由,这样一来,我的问题解决了

总结

* 大胆猜测,小心求证
* 换位思考,如果是我,我会怎么命名,这个常用于寻找分析入口点
* 英语别太差,不过一般来说你坚持看源码英语会提升的
* 不要 CTRL + F,不要 CTRL + F,不要 CTRL + F,多用 F12,查找引用
* 在某些特殊情况下,例如别人都是通过反射调用的,那么就只能 CTRL + F 了

可以看到,解决这个问题的过程几乎全是靠猜,猜错了就回过头去猜下一个,猜对了那就对了。所以如果说某个开源项目的命名太糟糕,那就确实不好找了。当你看源码看多了之后,你就不需要猜了,因为你已经知道命名是啥了。


在这个示例中,我们没有使用转到实现,因为其实这个示例所涉及到的代码还是简单的,没有涉及到太多的多态,因此不需要转到实现。如果涉及到多态,那么过程会复杂很多,因为要看的路径太多,但总归是能看完的,相比用谷歌去搜索半天压根就没有头绪,花点时间猜源码还是值的。