为什么以及要有的态度:
不要消极的去阅读别人的代码,而是带着挖掘宝藏的精神去寻找别人的代码中精华的部分,找出其中好的架构为我所用。
大体思路:
(1)忽略细节,先前不要关注分支(支线)。不重要的功能,一扫而过。
(2)先整体再局部,先宏观再微观,先流程再细节。从上而下了解,先不关心内部细节。
注意:从上而下了解,先不关心内部细节。
(3)阅读代码有两种模式:top-down 和 bottom-up。需结合起来使用;
方法:
(1)先建好环境,让程序能运行,玩一遍
(2)通过文档或者资料了解程序的架构;
(3)断点调试、日志调试。
(4)善用搜索引擎;在查找一些函数在项目中的脉络,以及一些变量或对象在项目的使用点,这样比较有针对性;
(5)写注释;从流程到细节,看流程时,只要把流程函数的功能注明即可,看细节时,就需要把难看懂的地方加注释,方便理解,和理清思路;
(6)绘制UML。这个方法适用于类之间的关系较复杂和调用层次较深的情况,我一般都是先绘制顺序图,然后为顺序图中的类绘制关系图。
注:Unified Modeling Language (UML)又称统一建模语言或标准建模语言,是始于1997年一个OMG标准,它是一个支持模型化和软件系统开发的图形化语言,为软件开发的所有阶段提供模型化和可视化支持,包括由需求分析到规格,到构造和配置。
(7)类的快速阅读。先弄清楚它在继承链中的位置,看看它的内部状态,也就是成员变量,一般来说,类的对外接口都是对成员变量的访问、加工、代理等,然后看看它的对外接口,也就是公有成员函数,识别核心的一个或多个函数,这时候你应该可以大概了解这个类的职责或作用了。可能这个类是某个设计模式中的一个组成部分,所以,设计模式的掌握对代码的快速阅读也是很有帮助的。
(8)带着问题去阅读。比如想了解Android中的消息机制,那么看看Looper、Handler、MessegeQueue这几个类就可以了,其他的不要去看,要不然就跑题了。
必要使用:
方法1, 2, 3, 4, 5,8;
选择性使用:
方法6:在代码的耦合性比较高时以及需要理清代码的逻辑的时候;
方法7:需要知道具体的类的作用的时候,需要考虑细节的时候;
进阶:
(1)了解别人的代码意图,然后再去修改,扩充,抽取,提炼精华。这是进阶的必经之路。
书:
「代码阅读方法与实践」
工具:
使用source insight工具
参考1:
如何快速看懂一个大型程序 - JYSG9的专栏 - CSDN博客
https://blog.csdn.net/jysg9/article/details/24193181
(1)先建好环境,让程序能运行,玩一遍
(2)看想办法掌握程序的结构;对于开源项目,通过作者微博、Google、百度、PDSN、等找到程序的体系结构,通常情况下是能找到些资料的。即使情况差一点,也能找到星星点点,而这些星星点点对你的研究往往有很大的帮助。
(3)先体系再细节;先平面再线点。
(4)断点调试、日志调试。
(5)忽略细节,先前不要关注分支(支线)。如有些函数一看函数名便知道是干什么的,没有要一开始便深入。
有些系统中的分支(如某此特殊场景下才执行的逻辑)、不重要的功能,则一扫而过。
(6)其它;善用搜索引擎,试试切换不同的关键字,往往有意外的收获。
先整体再局部,先宏观再微观,先流程再细节。
参考2:
如何快速的看懂别人的代码 - SunWuKong_Hadoop的博客 - CSDN博客
https://blog.csdn.net/SunWuKong_Hadoop/article/details/59108612
1、阅读他人的代码就要阅读其中的精华,站在巨人的肩膀上,让自己成为巨人。
2、不要消极的去阅读别人的代码,而是带着挖掘宝藏的精神去寻找别人的代码中精华的部分,找出其中好的架构为我所用。
3、了解别人的代码意图,然后再去修改,扩充,抽取,提炼精华。这是进阶的必经之路。
4、要了解别人的代码,首先要熟悉代码中的命名规范。
5、阅读代码的目的在于了解系统全貌而非了解细节。(感觉这句话没说好!)
6、心中必须有对架构的层次感,例如,如果谈到对事件驱动式的架构时,应该想到,这个系统主要有三个重要角色,事件调度,事件产生,事件处理。从上而下了解,先不关心内部细节。
7、从作者的角度去理解代码,理解架构。
参考3:
牛人教你如何阅读源码 - 哆来咪er的博客 - CSDN博客
https://blog.csdn.net/Maxbyzhou/article/details/51424595
1)、一边阅读代码一边写注释。这是我用过的最好的方法,对代码理解得更深入,看一些重要代码或者特别难懂的代码时挺有用。更何况,注释也是一种文档嘛。
2)、一边阅读代码一边绘制UML。这个方法适用于类之间的关系较复杂和调用层次较深的情况,我一般都是先绘制顺序图,然后为顺序图中的类绘制关系图。3)、通过Debug来跟踪程序的主要执行过程,这样就可以分清主次了,阅读的时候更有针对性。(前面参考有说到)
4)、类的快速阅读。先弄清楚它在继承链中的位置,看看它的内部状态,也就是成员变量,一般来说,类的对外接口都是对成员变量的访问、加工、代理等,然后看看它的对外接口,也就是公有成员函数,识别核心的一个或多个函数,这时候你应该可以大概了解这个类的职责或作用了。可能这个类是某个设计模式中的一个组成部分,所以,设计模式的掌握对代码的快速阅读也是很有帮助的。
5)、带着问题去阅读。比如想了解Android中的消息机制,那么看看Looper、Handler、MessegeQueue这几个类就可以了,其他的不要去看,要不然就跑题了。
下面列几个阅读源码时所处的情景,在特定场景下用哪些方法:
不太熟悉业务逻辑,还不是很清楚它是干啥的,可以用3、5。
代码量很大,有几十万行,甚至百万行,可以用2、3、5。
你无法看见程序的运行过程,比如没有用户界面,也有可能是无法运行的,可以用3、5。
设计复杂,用了大量的设计模式,调用链很深,可以用1、2、3、4、5。
时间有限,没有那么多时间让你看源码,可以用3、5。
以及:
1)读代码最忌讳的是不抓结构抓细节,只见树木不见森林
2)首先应该先了解代码的功能业务,在了解业务逻辑的情况下,进行代码阅读觉得是事半功倍的,可以先多用用列跑起来,看看功能。
3)阅读代码有两种模式:top-down 和 bottom-up。
Top-down 模式,就是先设定一个 use case,比如说打开一个文件。然后静态跟着代码看,或者用 debugger 跟着看。每次出现函数调用的时候,把函数的执行层次纪录下来。大致如下:
func1( )
func2( )
func( )
func3( )
这种图表很随意,你可以根据自己的需要增加信息。比如我有时会把重要的「实际参数」一直标下来,这样阅读深层次代码不用再回头查形式参数到底指什么。这个图的基本作用是防止在阅读深层次代码时忘记总体执行层次。
Top-down 模式进行到一定层次,往往会发现虽然图画了出来,但还是无法了解程序再干什么。这时需要转入 bottom-up 模式,一直深入到最底层,给能了解作用的底层函数一个一个的写文档。当然这时的文档是完全底层的观点。
然后就是不断在两个模式之间转换,不断的细化两种模式的理解。
4)「代码阅读方法与实践」推荐这本书
总结来说:
1、带着问题读(前面参考有说到)
2、对它先产生初步映像
3、使用source insight工具
4、使用debugger模式(前面参考有说到)
5、做好注释(前面参考有说到)