摘自http://blog.csdn.net/oncoding/archive/2009/08/11/4434315.aspx
源码阅读,自然是计算机学习的捷径之一,其重要性在此就不再赘述。
因项目需要,最近在读OpenSSH & OpenSSL 的源码库,一开始进展奇慢,龟速,后来掌握了一些技巧后,快了一些。在此,将我总结的所谓的“技巧”贴上来,我先扔出一块砖,大家拿玉的砸过来!!
读一份好的源码就像挖宝藏。
1.工欲善其事,必先利其器——铁锹?
源码阅工具推荐:
桌面软件或web开发推荐 ms vs 或eclipse+plugins,即相应的IDE即可;
linux项目相关推荐使用source insight(wine/samba)。
可以根据个人习惯确定。
2.选择好的项目——什么才算宝藏?
好的项目:质量过关的项目;
个人认为,质量过关的代码应该至少具备:
1)软件架构、模块接口设计良好,高内聚、低耦合;
2)代码书写规范、流程清晰;
3)注释、文档、及相关网络资料齐全;
具体到某个项目的优劣可以参考主流论坛对之的评价。
除此之外,好的项目,也必须是适合自己的项目。
根据自己的水平,兴趣,专业方向等做出选择,更多情况是因为一些限制条件,比如:工作或学习需要。
这样做的目的是,让我们能够有目标的去读,一则因为实际需要,易于端正态度、不会轻言放弃;二则于情景中阅读源码,更容易理解,事半功倍。
举例说明:
要学习 asp.net的架构设计、设计模式的相关内容,并且毕业设计想实现一个电子商务网站的,可以阅读一下 petshop;
如果要学习http协议的具体实现,可以阅读一些web server的源码,micro_httpd、shttpd、boa、apache……
如果学习龙芯或MIPs CPU架构,熟悉mips汇编,建议阅读mips模拟器源码,pcspim 、vmips、msim ……
……
3. 关注Doc——关于宝藏
很多开源项目中的readme、Q&A、buglist、manual等都会提供大量的信息,了解这些文档,显然会对整个项目的把握很大的帮助,然而这部分也是最容易被我们忽略的。
我们也可以通过 wiki & google扩展这些资料。
4.搭建环境——出发前的准备
一个可运行的环境对于代码阅读会有很大的帮助:
1)便于我们从功能面上了解项目;
2)通过调试、跟踪等手段,理解源码运行的流程。
5.分析项目架构——画地图
通过以上几步已经大体把握了项目的架构,我们再结合源码,即可分析出项目的架构,常用手段如下:
1)借助项目目录;
2)分析项目管理工具Makefile,分析模块的依赖关系;
3)浏览源码,这里不必具体到每个函数,遇到关键函数可以阅读注释即可;
4)阅读文档、借助google等
做到这里,我们已经对项目的架构应该有了七八分的了解,有些问题即使想不透彻也没关系,留到下面,咱们秋后算账。
在继续下一步之前,我们应该动手将项目的架构图画出来,和概要设计时的系统模块图类似,不清楚的地方空出来,可以借助visio、Rose、smartDraw等工具。
注:这一步是必须的,因为这是我们寻宝的地图,它可以使我们不至于迷失在茫茫的源码海洋之中。
6.深入源码——给我搜
根据上一步的地图,我们开始深入到各个模块,逐个歼灭,顺序大体如下:
1)自底向上的原则
这和我们在软件设计阶段自顶向下,逐步求精的思想相反;对模块内部的分析,我们需要从底部实现着手,结合地图,逐步cover此模块,蚕食之。这也是我们画地图的主要原因。
2)公共模块优先
公共模块基本上是一些通用性比较强的代码,可复用性比较高,例如一些工具性代码;
这些代码的模块接口通常比较清晰,这些代码基本上可以算是金子啦,这里的很多代码、甚至整个模块我们都可以直接用到其他项目中去。我们要将这些代码存入自己的代码库,这样还不行,我们还要加上这些代码的使用说明和可运行的实例代码。
3)虚拟数据,模拟接口,让每个模块都可以独立运行。
模拟这个概念比较重要,有点孤立敌军的意味。用虚拟数据包围当前模块、切断与其他模块的关系,将模块独立开来,歼灭之。
这一步需要的技巧比较多,难度通常和所选的项目有关,这也是前文中我们强调低耦合的原因。关于这些我们可以参考单元测试中的Mock原理,在书写大量伪装数据的同时,我们对模块间接口交互、数据流等有了更深层的了解。
这一步我们可以站在软件设计者的角度来思考,此时应该可以写出此模块的详细设计文档。
7.总结
一个源码项目阅读完了,我们再要回顾整个过程,把开始地图中留下的空填上。
我们不能满足于抽取了一些代码,对这个项目甚至类似的项目有了一些了解,这些仅仅是鱼;更重要的是要学会打渔的方法,正所谓:千金在手,不如一技傍身。
早期共产党为啥能够在如此艰苦的环境下存活甚至发展壮大,个人认为,主要是源于不断地思考和不断地总结!我们要时常猜测设计者的设计意图:
为什么这样做?为什么不那样做?
如果是我来设计,我应该怎么实现?应该避免什么,注意什么?
这样做真的最好吗?有没有其他更好的实现方法?
把这个将这些思路整理出来,可以称之为源码阅读心得。
就这样我们阅读一个项目基本上三遍就差不多了:
1)浏览,得出模块设计概要图;
2)细品,得出模块的详细设计,丰富了个人代码库;
3)回顾,得到此项目设计的精髓;
最后不要忘记在相关主流社区共享这些资料,留下联系方式,如有纰漏,会有人给你指出的,人人为我,我为人人。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/oncoding/archive/2009/08/11/4434315.aspx