开放源代码的项目，通常都是不完整的，就是说：只有源代码，没有完整的产品使用说明书，没有软件开发过程中的完整文档，源码中的注释也很少。之所以会这样，可能是因为作者们有所保留，只开放源码，不开放关键的文档和设计思路，还可能是因为作者们都是旧派的程序狂人，不重视软件工程和文档。
那我们该怎么办呢？ 只有一条路，就是自己动手来补齐缺少的所有关键文档。补齐项目的文档，跟开发一个新项目有所不同，因为项目的源码已经编写完成了，所以，这是一个相反的分析设计过程。
下面就具体说说该怎么办：
1.一个开放源代码的项目，总得带有一点说明吧，这就是最初的线索。即使是几句话，也很重要。
2.下载了源码之后，就应该开始编译源码了，这时候，就应该编写一个“源码编译方法”文档。这个文档很重要，因为如果源码没法编译，就是废物一堆，毫无价值。
“源码编译方法”文档，应该标明：
操作系统版本，获取的方法。(获取的方法通常是：从某某网址下载，从科技市场购买，保存在自己的那张光盘中)
操作系统补丁的版本，获取的方法。
编译工具版本，获取的方法。
编译工具补丁的版本，获取的方法。
第三方工具的版本，获取的方法。
编译环境的设置方法，例如VC的Include路径，库文件路径，这些地方虽然都是小问题，但是，弄不好，就无法编译通过。
有时候，源码也需要修改，因为作者不一定是中国的，所以，源码中的字符串可能会变成乱码，所以，必须要改一下。还有，因为语言的不同，可能也需要改一改。
3．源码编译通过了之后，就要开始研究使用程序的方法了。有的程序很容易使用，有的就不行了，很难使用。要写出“产品用途和功能的介绍”和“产品使用方法说明书”。写这两个说明书，一个重要的目的是 分析软件产品的需求。产品需求就相当于“客户给你出的一个题目”。
4．需求搞好了之后，你可以先自己想一想这种需求该怎么实现？你自己能不能搞出来？这就是一个解题的过程。
如果你自己解不出来，就可以看看答案了，就是看源码了。
现在开始正式分析源码，怎么分析？当然是根据产品的使用方法，来跟踪流程了。由于“产品使用方法说明书”已经有了，所以，源代码就很容易理解了，可以往产品的功能上靠。当然了，有时候产品的功能和使用方法无法事先分析清楚，这时候，就需要边看代码，办猜测软件的功能和使用方法了，这样做很累的，是没办法的办法了。
看源码的时候，应该同时编辑着两个文档“程序总体结构报告”（包含 程序流程图）和“源码分析报告”。前者是用来获取程序的总体结构用的，后者，是一个笔记本，记录中源码分析过程中遇到的所有的难题，源码阅读到什么地方了，阅读源码过程中的感想，获得的启示，重大的发现等等。需要强调的是，“程序总体结构报告”这个文档相当重要，特别是项目比较大、代码比较多的时候，这个文档就显得尤为重要，否则，你可能就会在无数行的代码当中迷失了方向。很多程序员的通病就是太注重细节，却忽视程序的总体结构，这就导致了阅读源码的速度很低，思路不清，不容易抓住重点。所以，一定要重视对“程序总体结构”的分析，要从细节的纠缠中解脱出来。虽然细节问题很重要，但是，“程序总体结构” 更重要。
在“程序总体结构报告”中，“程序流程图”是最重要的部分。对于不太大的项目，只需要一个“程序流程图”就够了。
“程序流程图”最好用Visio绘制，这个工具非常好用。如果没有这个东西，用Word或其它的绘图工具也可。
