有个朋友看了我的博客,发信问我如何读源码。说实话,我在读源码的过程中也并不顺利。最初,我希望能好好读读linux的源码,可惜的是linux太庞大 了,虽然学了不少时间,但是觉得还是前路遥遥。有时也感觉庞大的代码库有些无处下手,才选择了eCos。eCos体积非常小,感觉读起来轻松很多,有了 linux的一些学习基础,对理解ecos也很有用处。

    现在已经进入开源时代,有很多开源的项目,大量的代码需要读。如何读源代码可能是很多人面临的问题吧。我想,根据自己的经验教训,总结一些想法,希望对别人,对自己都能有所启发。

1. 耐心和坚持

    读代码很枯燥,所以需要耐心和坚持。其实,学什么都一样吧。

2. 实践

    很多时候多跑一跑能够更清楚的得到结果,而且有的时候光读,理解不一定正确,必须跑起来才心里有底。  说这个也是因为我自己比较懒得动手,所以吃了不少亏。

3. 分治

    即分而治之。遇到一个大问题总是会有望洋兴叹之感。可是,如果能把一个大问题划分诸多小问题,马上会感觉目标清晰很多。 当每解决一个小问题,也能知道自己离最后的目标有多远。

4. 多方面入手

    前面提到分治,但是在读源码时,如何将诸多代码进行划分呢?
依据我的经验,提供以下3个思路:

    一、根据运行流程,程序就是一个执行流程,根据执行流程将程序划分出若干运行阶段,然后再逐步求精。比如,我前面的系列文章: 《Redboot(i386)启动流程》就是完全按照执行流程来分析的。根据运行流程读代码的时候,就要尽量打开项目本身的DEBUG信息,或者自己添加 一些代码测试,确认运行状况。

    二、根据项目组织结构和编译过程。项目本身会划分诸多模块,通常根据makefile可以大致了解项目的组织情况。另外,了解项目编译过程对理解项目也是非常有用的。

    三、从一些主题入手,比如对于ecos,可以提出很多主题,比如:跟踪收发包过程去了解其网络处理流程,跟踪命令执行过程,跟踪中断处理过程等等。从不同侧面了解你所读的代码,会让你对整个项目有更清晰的认识。

    读代码的时候,经常会碰到读到没有路的感觉,或者不想读下去了。这时候,换个思路,换个目标,也许就能再继续下去。有的时候,分兵出击,会起到意想不到的效果。

5. 记录

    当一段代码读完,尽量记下来自己的理解,否则回头再看,又没有印象了。人们有时候喜欢太高估自己的记忆力,我以前特别不喜欢记,后来不得不记了。可是,有时候,时间一长,甚至自己记得东西都不太看得懂了,呵呵。

6. 学习相关知识

    对编译工具 make(makefile), gcc要了解,对嵌入式软件还需要对cpu有了解。另外了解链接和程序加载过程(ld,loader and linker)也是很有帮助的。开源项目的编译和环境搭建大多在linux下,所以对linux,shell等也都要了解。这些东西内容不少,要慢慢来, 还是要坚持和耐心,多动手。

7. 借鉴别人的思路,多参考书

    学linux有不少书,比如:《linux 0.11源代码完全中文注释》《LINUX设备驱动程序》都很不错,学ecos,现在看到最好的就是:《EMBEDDED SOFTWARE DEVELOPMENT WITH ECOS》虽然,有几本中文书感觉并不是很好,不过还是可以参考一下。网上也有不少关于ecos/redboot的小文章,也挺不错的。

8. 目标明确,急用先学

    有明确目标的学习通常效果最好,很多时候不一定有时间完完全全把一个项目了解清楚才能用。项目来了,找到明确目标,就去学,分清长线和短线。学以致用。

    大概想了这么些。很多事情刚开始起步都很难,不过慢慢做就会越来越熟练,越来越有经验技巧。所以,我才认为耐心和坚持最重要 ^_^

---分割线---
 
上次聊过这个话题,不过最近又在读代码,这次不是读redboot,而是读一个网络协议栈的代码。协议还是蛮复杂的,代码很多,更郁闷的是没有运行环境。所以,只能摸黑读代码,很多不懂的地方只能靠猜了。还是,有些体会,记录一下:
 
1 Programs = Algorithms + Data Structures ,通常读代码的时候,可能更关注执行的流程。其实,数据结构应该给予更多的关注,数据结构相比执行流程,代码量少的多,却更容易体现设计者的思路。

2 协议,文档和注释。有的算法比较复杂,看代码会很累,所以要注意文字性的描述,比如协议规范,程序注释,已经附带的文档。搞清楚代码想做什么,然后看起来可能会更清楚了。

3 把注意力集中在主干流程上。 程序的流程错综复杂,有很多代码是针对错误处理,或者一些其他情况。也会有一些宏来区分不同平台,硬件等等。所以,一开始不要太执着于细节,首先理清楚自 己所关注的流程上。把整个流程走通,然后把流程中的细节问题读懂,之后再去读与流程相关的其他情况。

4 推荐一个工具,freemind,  用树形的结构来整理函数的调用过程还是不错的。这次帮我不少忙。
 
5 画图推演,对一些算法,不要光读,要用笔画图演示一下执行过程,更直观的领会程序的功能。

 

 

原文地址 http://redboot.blogbus.com/logs/22623708.html