源码阅读学习的捷径

源码阅读，自然是计算机学习的捷径之一，其重要性在此就不再赘述。

因项目需要，最近在读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)回顾，得到此项目设计的精髓；

最后不要忘记在相关主流社区共享这些资料，留下联系方式，如有纰漏，会有人给你指出的，人人为我，我为人人。