如何研读开源项目代码

今天在微博上看到庄表伟在知呼上回答的如何更有效地学习开源项目的代码？

我很认同他总结的 “学习开源，就尽可能在代码里找答案，而不是在代码之外找答案，那些都是二手的，而且很可能是不准确的。”  但是如何读好，读懂代码，我这边还是有不同的认识。

 

1. 需要从代码管理库下载完整的源代码，而不是简单的源代码文件包或者source.jar.

    这样做有很多好处，一个是你可以获取代码的修改记录，还有你可以获取到完整的测试代码，当你要提交patch的时候，你可以借助版本管理工具生成针对不同版本的patch。

 

2. 示例代码与单元测试

    示例代码可以帮助你学会使用相关开源项目的API。很多朋友在使用开源项目的时候遇到一个小问题就发信给开发者要这样或者那样的示例代码，其实他们没有发现大部分的开源项目在开发的过程中，为了验证其实现的功能，都会写很多单元测试代码。这些代码其实非常好的示例代码。可能是下源码，建工程会花费你几个小时的时间，但是如果你想深入了解开源项目的话，这点投资还是很有价值的。

 

     其实读单元测试的好处太多了，这里简单给大家列一下：

• 由于一个单元测试一般也就是几个小时的开发工作量，你很容易就能读懂相关的代码。
• 每个单元测试都是可以独立运行的，这样节省你跟踪调试的时间。
• 单元测试在很大程度定义了软件的功能，可以帮助你快速掌握项目的相关API。
• 如果你修改的开源项目的代码，你可以通过修改单元测试来验证你的修改是否正确。

3. 架构文档

     其实大部分的开源项目都会对其架构有一定的描述，这些描述可能会有点过时，但是通读一下会让你项目有一个比较深入的认识。这样做好比是让你对北京的二环，三环，四环，五环有个大体的认识。这样在你要对代码的某块内容进行详细研究的时候（例如找中关村的位置的时候，知道西北四环）就能很快定位了。

 

评论

12 楼 Mybeautiful 2012-01-19  

前段时间在下也有一篇阅读源代码的文章,总的观点跟博主类似，不过我觉得动手调试是最重要的；
http://mybeautiful.iteye.com/blog/1156815

11 楼 jnn 2011-12-21  

jnn 写道

不知道你如何下载的源代码，现在spring framwork的代码可以从github下载了，你下载之后可以按照下面的步骤在编译生成工程文件。看上去Spring3使用的是Ant 而不是使用maven。

如果你不是要通读Spring的代码，同时也不打算修改Spring的代码，你可以使用maven eclipse:eclipse 来建立一个简单工程文件当然你需要在你的工程里面指明对Spring的依赖，这样maven会帮助你下载soure.jar 文件，你用eclipse是可能跟踪到spring代码内部的。

10 楼 jnn 2011-12-21  

mlc880926 写道

我构建开源项目就没成功过,比如spring的源码,我直接装了eclipse的maven插件,然后导入spring的maven,但肯定有X,依赖一直有问题
博主有看过类似经验吗,望指教

不知道你如何下载的源代码，现在spring framwork的代码可以从github下载了，你下载之后可以按照下面的步骤在编译生成工程文件。看上去Spring3使用的是Ant 而不是使用maven。

9 楼 mlc880926 2011-12-21  

我构建开源项目就没成功过,比如spring的源码,我直接装了eclipse的maven插件,然后导入spring的maven,但肯定有X,依赖一直有问题
博主有看过类似经验吗,望指教

8 楼 downpour 2011-12-21  

jnn 写道

我写这篇日志的主要目的是让大家在看代码的时候也留心一下单元测试，里面有很多宝藏。

好的单元测试不一定要把整个系统启动起来，因为这样做会耗费很多时间，而且单元测试跑得慢会降低开发人员跑测试的积极性。

单元测试已经把问题分解了，如果使用了mock对象，debug的过程中可能不能完全体现整个运行环境的情况。 这部分的工作可以由示例代码(example)来补足。

对于我参与的开源项目 Apache Camel来说，camel-test 模块中已经对启动环境进行了封装，用户只需要更改route 配置代码结合mock endpoint就可以进行测试了。如果只想验证代码写是否正确的话，这样的单元测试（测试业务模块）是很值得推广的。

我完全明白你的意思了。我顺着你的思路去看了一下XWork中的一些单元测试基类，果然发现了不少好东西。谢谢！

7 楼 jnn 2011-12-21  

downpour 写道

jnn 写道

downpour 写道

兄弟，你把人家最精髓的第一句话给漏了吧。人家最提倡的就是去debug源码，其次才是单元测试啥的。

debug源码最大的好处是可以看到源码的运行状态。实际上单元测试应该是一个局部的源码阅读方式，旨在解决某个领域的问题。

读代码不是看小说可以一页的看，有了单元测试就像是有了一个贴身导游，你可以让他带着你边走边看。

单元测试是很好的方法，不过老实说我觉得有点纸上谈兵的味道。因为单元测试所模拟的往往只是一个功能模块而不是整个运行环境。所以我认为只有把系统在一个轻便的环境中运行起来并且进入debug模式才是阅读的王道。

我写这篇日志的主要目的是让大家在看代码的时候也留心一下单元测试，里面有很多宝藏。

好的单元测试不一定要把整个系统启动起来，因为这样做会耗费很多时间，而且单元测试跑得慢会降低开发人员跑测试的积极性。

单元测试已经把问题分解了，如果使用了mock对象，debug的过程中可能不能完全体现整个运行环境的情况。 这部分的工作可以由示例代码(example)来补足。

对于我参与的开源项目 Apache Camel来说，camel-test 模块中已经对启动环境进行了封装，用户只需要更改route 配置代码结合mock endpoint就可以进行测试了。如果只想验证代码写是否正确的话，这样的单元测试（测试业务模块）是很值得推广的。

6 楼 downpour 2011-12-21  

jnn 写道

downpour 写道

兄弟，你把人家最精髓的第一句话给漏了吧。人家最提倡的就是去debug源码，其次才是单元测试啥的。

debug源码最大的好处是可以看到源码的运行状态。实际上单元测试应该是一个局部的源码阅读方式，旨在解决某个领域的问题。

读代码不是看小说可以一页的看，有了单元测试就像是有了一个贴身导游，你可以让他带着你边走边看。

单元测试是很好的方法，不过老实说我觉得有点纸上谈兵的味道。因为单元测试所模拟的往往只是一个功能模块而不是整个运行环境。所以我认为只有把系统在一个轻便的环境中运行起来并且进入debug模式才是阅读的王道。

5 楼 jnn 2011-12-20  

downpour 写道

兄弟，你把人家最精髓的第一句话给漏了吧。人家最提倡的就是去debug源码，其次才是单元测试啥的。

debug源码最大的好处是可以看到源码的运行状态。实际上单元测试应该是一个局部的源码阅读方式，旨在解决某个领域的问题。

读代码不是看小说可以一页的看，有了单元测试就像是有了一个贴身导游，你可以让他带着你边走边看。

4 楼 FX夜归人 2011-12-20  

学了，谢谢。

3 楼 downpour 2011-12-20  

兄弟，你把人家最精髓的第一句话给漏了吧。人家最提倡的就是去debug源码，其次才是单元测试啥的。

debug源码最大的好处是可以看到源码的运行状态。实际上单元测试应该是一个局部的源码阅读方式，旨在解决某个领域的问题。

2 楼 DiaoCow 2011-12-19  

正好在学习看源码，遗漏了看单元测试这么好的方法，学习了！

1 楼 gteam.yu 2011-12-19  

呵呵，这个不错，其中单元测试是重点，一般的框架下载都附上了单元测试代码的，都单元测试容易理清整个框架，也能专注于某一个部分的功能。