DSP

如何快速看懂一个大型程序

2019-07-13 20:18发布

为什么以及要有的态度: 不要消极的去阅读别人的代码,而是带着挖掘宝藏的精神去寻找别人的代码中精华的部分,找出其中好的架构为我所用。   大体思路: (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、心中必须有对架构的层次感,例如,如果谈到对事件驱动式的架构时,应该想到,这个系统主要有三个重要角 {MOD},事件调度,事件产生,事件处理。从上而下了解,先不关心内部细节。 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、做好注释(前面参考有说到)