快速阅读大型嵌入式C代码方法汇总

来源:互联网 发布:思科mac地址 编辑:程序博客网 时间:2024/06/06 02:11
1、 阅读代码要做的第一件事情是收集所有和项目相关的资料,例如:需求分析报告、概要设计报告、详细设计报告,使用手册、测试报告等,尽量多收集对你以后的代码阅读是很重要的
2、从main函数入手根据调用大致掌握整个代码的架构和模块,主要模块的初始化和划分一般都是在main函数里,所以第一个要从main函数入手。
3、根据初始化函数和线程函数来切入某一模块,因为一个模块的开始肯定是初始化,而且常常一个复杂的模块往往要建立一个线程,在线程里会逐步展开整个模块的布局。
4、细分到某个具体模块时可以根据充当发送和接收消息的媒介的全局变量来显示大致的架构,这个要借助source insight的reference功能来查看。如下图:打开reference功能,点击插入队列或弹出队列调用处的全局变量decodeThreadInfo,则reference列表中就会出现有一下接口使用了队列传送消息。这样就可以大致知道了这个模块的大致流程了。


5、学会根据状态标志来快速掌握某个模块的大致流程。一般一个状态标志就是这模块的一种运行的过程或状态,若是状态标志表示的一个连续的过程如登录,则这就容易知道程序运行的流程了,一般也对应着一个控制接口,所以可以根据状态标志大致知道这个模块的运行流程。
6、带着调试,运行的方式理解代码。
7、通过在代码增加log的方式,先理解数据流动的方式,再理解各个模块的设计目标,随后才是一些函数之间的逻辑相互对应关系。
8、使用gdb设置断点,一步一步地进行跟踪。
9、使用reference功能查看全局变量,可以大致知道总共有那些地方知道与这个模块有关联。
10、分层次阅读, 在阅读代码的时候不要一头就扎下去,这样往往容易只见树木不见森林,阅读代码比较好的方法有一点象二叉树的广度优先的遍历。在程序主体一般会比较简 单,调用的函数会比较少,根据函数的名字以及层次关系一般可以确定每一个函数的大致用途,将你的理解作为注解写在这些函数的边上。
11、写注解是在阅读代码中最重要的一个步骤
    1)猜测的去写
    刚开始阅读一个代码的时候,你很难一下子就确定所有的函数的功能,不妨采用采用猜测的方法去写注解,根 据函数的名字、位置写一个大致的注解,当然一般会有错误,但你的注解实际是不但调整的,直到最后你理解了全部代码。
    2)按功能去写
    别把注解写成语法说明 书,千万别看到fopen就写打开文件,看到fread就写读数据,这样的注解一点用处都没有,而应该写在此处开发参数配置文件(****。dat)读出 系统初始化参数。。。。。,这样才是有用的注解。
    3)在写注解的使用另外要注意的一个问题是分清楚系统自动生成的代码和用户自 己开发的代码
    一般来说没有必要写系统自动生成的代码。象delphi的代码,我们往往要自己编写一些自己的代码段,还要对一些系统自动生成的代码段进行 修改,这些代码在阅读过程是要写注解的,但有一些没有修改过的自动生成的代码就没有必要写注解了。
    4)在主要代码段要写较为详细的注解
    有一些函数或类在程 序中起关键的作用,那么要写比较详细的注解。这样对你理解代码有很大的帮助
    5)对你理解起来比较困难的地方要写详细的注解
    在这些地方往往会有一些编程的技巧。不理解这些编程技巧对你以后的理解或移植会有问题。
    6)写中文注解
12、重复阅读,在第一次阅读代码的时候 你可以跳过很多一时不明白的代码段,只写一些简单的注解。

大神方法
    源码阅读其实是一个逆向的工程,这期间必须会遇到种种问题。一般来说,我会遵循这样一个思维范式——Problem domain→model→architecture&implementation→improvement→best practice。

1. 首先搞清楚要分析的产品解决的问题是什么,这个问题在哪个大的范畴里,也就是要搞清楚problem domain。一个著名的开源产品必定在Wikipedia上有相应的条目,所以一开始去看wikipedia是破题的一种极好方式。

2. 清楚要分析产品的大体框架和关键性的概念,也就是理解清楚architecture和key concept。

3. 将分析的产品实实在在的运行起来,我一般选择debian或archlinux作为工作平台,它们提供了丰富的软件包,可以很快的将东西安装并运行。熟悉Linux本身对于开源项目的源码阅读还是大有裨益的。

4. 修改日志级别,得到丰富的日志信息。有了这个为基础,再来开始真正的源码阅读和分析。

5. 源码分析的时候,要始终问这几个问题。

    - 进程以及线程的启动顺序
    - 搞清楚调用关系call flow
    - 这一部分代码是在同一个进程中么,同一个线程中么,运行在同一台机器中么
    - 每一个线程都要问清楚,什么时候启动的,什么时候停止的
    - 消息传递的路径,针对每一个函数,搞清楚,input是谁传给我的,output要传给谁,由哪个来传
    - 搞清楚上述的问题之后,就将最开始提到的对architecture的了解做到具体而微了。有了这个基础之后,再继续往下问
    - 当前实现的性能如何,比如i/o, cpu, network 这个需要做相应的测试方面的试验
    - 当前的解决方案还有优化空间吗,比如针对spark中的scheduling问题,就有sparrow的优化机制提出

6. 碰到具体的问题一时解决不了怎么办

    - 用好google,用好stackoverflow
    - 将碰到的问题模型化,写一些验证性的代码,或者是写一个小的demo来验证,我在解决许多很妖的bug,也是采用类似的思路
    - 找到相应的用户论坛,发帖虚心请教
    - 如果还是不行,就先搁一搁,去看能看懂的地方



0 0
原创粉丝点击