代码不要忙着细读。要粗，找到大体的脉络。
要改。根据自己的设想，大胆去改，改了之后就运行，看看是否有预想的效果。动手才能有收获。
找简单的任务赶快做起来。上司没有布置任务，就自己给自己布置。
不要偏执，做不出来的事情不要硬撑，要及时放弃，或者求教。
了解全局的时候，关注执行流程、层次、调用之类的，对细节不求甚解，看不懂的，底层的，跳过就是。
读细节的时候，就只读系统内自己关注的某个点，甚至某个具体的方法或者函数，一行一行慢慢啃。
读代码和写代码一样，你得先明确目标。漫无目的的读代码是不会有结果的，就如你自己都不知道写什么功能的情况下，能写什么代码？
既然明确你想了解的具体功能，接下去就简单了，你只要找到这个功能的切入点，按代码顺序读下来就可以了，读代码的速度取决于你对整体代码的熟悉程度，刚上手肯定会慢一点
整个过程中最关键的是找切入点，我看了很多新手程序员根本找不到他想看的功能该如何看起，那就需要一些技巧了，找一些不会变的关键api来作为索引的关键字，比如网络相关的肯定有recv，文件相关的也就是fread这样的一系列函数。
没有做关注点分离的代码就像图像处理软件里面多个图层最后“Merge Visible”的产物，一般来说除了原作者谁也还原不了最初的思路，除非遇到水平远远高出的高手。他能还原是因为他很早以前做过一样的事，知道中手的思维方式
重构的过程真的是这样，你会发现首先要把代码用一种重构手法整理完之后，才能够再用另一种重构手法对解开的代码进行进一步的整理
根据我的经验，把握粒度很重要，每行每行读是不现实的，这样容易造成只见树木不见森林，但是又不能读的太粗糙，否则错过很多精华部分，以c代码为例，我一般是先以文件为单位，看看每个文件大致是干嘛的，然后再以函数为单位，这时不关心函数的具体实现细节，而是将注意力放在函数接口上，大致理解下函数的意图，控制流的流动等，然后觉得哪个函数比较重要，在看看其实现。。。
如果一上来就一行一行的啃就图样图森破了，上述过程完成之后，如果还有余力，最好亲手实现一下，正所谓知者行之始，行者知之成，知行合一，如果能自己写一个，就说明真的掌握了。。。
好像没人说这个。。。应该先打开它的trace或debug日志，跑起来，然后跟踪日志，可以最快的熟悉代码
读代码切勿一开始就钻进一些细节。就像工作中接触一个新项目，新人也是从解bug 开始。带着目标问题去读，效果更好。
要掌握一个整体架构，不妨自己动手画出一张完整的类图，对于理解代码架构非常有帮助。
一些主要的业务逻辑，继续画些流程图顺序图，就一目了然了。
最后才是语法方面的问题。我认为好的代码一定也是阅读起来超爽的......
如果没有技术文档，就阅读所有能找到的材料。项目介绍，wiki，源码包的readme等。明确项目的目标，应用场景，甚至是用到的技术方案。
根据源码包的架构，以及了解到的用到的技术方案，大概猜测一下各个模块的功能。
同样浏览所有的源码文件，通过文件名字猜测其功能。
推荐使用某些代码阅读工具，如source insight，开始通读代码。阅读的顺序就比较灵活了，可以按照模块来阅读，可以先大致浏览核心部分再到外围代码，或者反过来从外围到核心包围。
经过第四步的通读，大概就能明确各个模块的功能以及各模块之间如何结合的了，这时在心里已经对整个代码结构有个大致的印象了。如果做不到，就重做第四步。
细读部分代码。比如你感兴趣的部分是如何实现的，或者核心部分的细节。同样我认为，带有某种目的的阅读更有效，比如想借用某部分的实现思路，想改进某部分，那就针对自己的目标部分进行重点攻破。
经过以上几点，相信整份代码已经都理解的七七八八了。再往下做什么相信都不会是障碍了！
是的，我们这边提到了一个重点，阅读程式码的目的在于了解系统的全貌，而不是在于只是为了地毯式的读遍每一段程式码。
这是一个很重要的关键，当你试着进到最细节处之前，应该先试着找出参与的角色，及他们之间的关系。
不论某个系统所采用的架构是否为大部分人所熟知的，在试着探索一个系统的长相时，我们应该找出来几个答案，了解在它所用的架构下，下列这件事是如何被完成的：一，系统如何初始化，二，与这个系统相接的其他系统（或使用者）有那些，而相接的介面又是什么;三，系统如何反应各种事件，四，系统如何处理各种异常及错误。
