我心里一直觉得，现在的环境下，源码阅读能力比源码编写能力更重要，因为很多人都发明了各种各样的轮子，现在只需要理解轮子的运行，维修轮子就可以了。这个想法对吗？有一点对，但是太肤浅了，不能拿着个当成不用编程的理由。我一直认为软件工程师是设计师圈子里的，设计师的学习三个阶段：守，破，离。总结的太好了，为什么我现在觉得源码阅读比编写更重要，因为我还处在“守”这个阶段！为了突破这个阶段，我要不断的阅读源码，获取更高层次，更抽象的知识，为下一阶段“破”打基础。
小时候，一直很迷恋武侠小说，很羡慕里面的主角，总是能在机缘巧合的情况下获取高深，尖端的武侠秘籍，然后一夜飞跃。现在在我面前摆着一本本武侠秘籍，每本都是牛逼大发的，但是问题是我能不能看懂？
阅读源码的目的是解决问题，而不是为了阅读源码而阅读源码，有的人写了十几篇博客，将源码中的一行行代码都解释了一遍，但是到了真正解决问题的时候又一头雾水。如何避免自己进入这一的误区？问题驱动的源码阅读（Question Drive Reading），在问题语境中理解源码。容易进入上面提到的误区的原因是什么？在你埋头于代码时，容易只理解了软件的静态结构，忘记了代码的动态变化。而现实问题环境中，往往需要你对软件的动态环境做出迅速判断的。比如虚拟机从光盘启动突然变得很慢，是什么原因？服务器上某些虚拟机突然cpu占用率很高，怎么找原因？其实我也不知道。但是，如果你对软件架构理解很透彻，那么第一步定位问题，应该能很迅速反应。比如第一个问题：第一反应是加载慢还是运行慢？通过查看进程IO可以判断，当时并没有过多的IO操作，那么可以判断是Guest OS运行出问题。这个问题是基于我工作中的具体语境的，还有其他问题描述没有说，只是举一个简单的例子。
如何阅读源码？问题驱动！
