*文中代码字体版权说明
附录A
作者经常思考如何读一份陌生的代码，最近有一些想法，现在将其展示给各位读者。
现有的源代码都是你的资源，但是这些代码良莠不齐，需要取其精华、去其糟粕。对作者而言，一般先对源代码进行搜索，找到函数入口，读懂入口函数，然后一层一层地向下递归，展开单步调试，调试代码输出变量的值。写Python代码和写Objective-C代码很重要的一点是要调试好。
如果入口函数是大的if…else结构，那么每一个分支就对应一套处理逻辑。分支里一般都是封装好的调用函数，直接调用那些函数就可以。调用函数里再调用的结构体、数组都可以一步一步跟入。如果入口函数只是一个事件循环，对于事件队列里的事件进行分发，将其交给后续的事件处理程序进行处理，就可以从事件队列的初始化、事件进入队列、处理程序如何注册等内容阅读下去。尽可能编译、调试，能调试的代码，几乎没有不能看懂的。
读代码通常要能回答下面两个问题。
要解决什么问题？
解决方案是如何实现的？
大到整个项目，小到一个模块、函数，读的时候，都要带着这两个问题去读。读完了，能答上来这两个问题，才有效。代码不仅要读，还要“理”和“试”。
具体可以这样做。
第一，理解需求。代码的作用是什么？如果可能，首先，做一个背景调查，如看官网介绍、维基百科等，了解主要功能，适合应用的项目，以及同类的框架。其次，写demo，调用API，理解接口的设计，使用框架至少参照入门示例做个小 demo。然后，调试，单步跟踪，理解各模块的联系和调用层次。最后，理解其中的哲理、性能和功能的取舍等。你要看的不只是语法上的技巧，更重要的是设计上的思路和原理。判断读没读懂最简单的标准是，假如给你充足的时间，你有没有信心写出一个差不多的东西来。
第二，了解代码的生成机制。自己先思考，如果你来做，该怎么做，再看源代码。比如，“输出日志的时候是异步的吗？如果我需要把日志输出到另外一台机器上，我该怎么做？”带着这些问题去思考解决方案。盲目地看所谓的源代码，没有任何意义。最适合看源代码的情况就是，你对某一个功能感兴趣，所以你想要了解源代码。
另外，读代码的时候要多读几遍，才能读出感觉来。比如，你看某个函数抛出了一个 up_call_info，就应该猜到这应该是个自定义结构体，用来当作message 传递给上层，没准与之对应的还有一个 down_call_info。
在阅读代码的时候，下列方法有助于你更好地理解代码。
看git历史。
拖进source tree，查看提交代码的历史更改，从第一个commit开始读，而不是最后一个。
一定要运行代码。不运行代码，并不一定能看懂。
借助IDE的代码结构分析工具。
在IDE里阅读代码。在IDE里可以跳转、查看定义，比在网页上看代码的效率高得多。比如，在Visual Studio中可以自动生成代码结构图及调用关系图，在Notepad++中可以自动折叠代码。
找到合适的代码。如果直接看Nginx的源代码应该看不懂，如果看HTTP 服务器的几十行源代码，应该是可以理解的。最重要的一点是理解代码的历史，理解代码的发展过程，从小到大的过程，理解功能为什么一步一步地被添加。
留意“代码指纹”和联系方式。代码不是凭空变出来的，写代码的人会在博客或书上留下痕迹，比如，留下思路、论文和联系方式等。其实解决很多疑惑的办法是直接联系相关代码的作者。
调试代码。
画UML图。UML图不是没用的图，它会告诉你如何分析代码。UML图包括动态图、静态图、类图、部署图、用例图等。
仿写代码。仿写代码耗费的时间比较长，但是照着写一遍，是有益处的。
买书。知识比钱值钱，时间比钱值钱。看书可以节约很多思考的时间。如果是十分知名的开源项目，在网上一般可以搜到“×××源代码结构分析”之类的书或者文章，参考类似的资料就可以，即使文章并不是很完整，也可以起到比较好的梳理作用。