CSDN前辈经验借鉴。
原文地址：http://blog.csdn.net/oncoding/article/details/4434315
源码阅读，自然是计算机学习的捷径之一，其重要性在此就不再赘述。
因项目需要，最近在读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)回顾，得到此项目设计的精髓；
最后不要忘记在相关主流社区共享这些资料，留下联系方式，如有纰漏，会有人给你指出的，人人为我，我为人人。
欢迎转载，烦请注明来自see-see