阅读源代码



  众所周知，要想写出好的程序，除了要经常写之外，还有看看别人是怎么写的，所以读别人的程序是非常重要的；如今是个信息交换十分发达的时代，你可以轻易的就看到顶尖级选手的代码；开源事业蒸蒸日上，确实是所有程序员的福音。但如何阅读别人的代码呢？尤其对于初学者而言，确实是个难题，就像碰到一漂亮的刺猬，实在不知道如何下嘴。

 

     规则一，你读的越多，你就越容易读懂，因为高手写程序的思维都是趋同的，正所谓万剑归宗；当然你要找到这个“同”，是需要功力的。设计模式是“同”之一，一般碰到同类型问题，大家都倾向于用同样的“模式”处理，所以你了解了这种模式，下次你看某个源程序时，其中有类似问题，你肯定就会想到作者很可能是用这种模式处理的。这样你就会更容易看清作者的思路，理清程序的脉络。

 

    规则二，由上之下，逐步求精。不要一开始就想把所有的细节搞清楚，否则你就会陷入“只见树木，不见森林”的困境。先要理清程序的脉络，知道那个包是干什么的，那个类是干什么的，他们之间有什么样的联系。然后在一个一个问题深究。其思想就是，大而化下，再大而化小...你要细到什么程度，取决于你的要求及期望。一般我看到包，类一层就不会看了，除非我对某个算法感兴趣，我也会仔细在研究之。其实这也是面向对象的设计思想，由上至下，而不是由下至上。无论你看到哪一层，你都可以说“我了解这个框架的实现”，只是看到的粒度不同而已。

 

    规则三，调试。我认为调试程序员最重要的功底，而不是最重要的之一。断点下在哪里最有可能定位问题所在，但又不浪费时间，记住断点并不是越多越好。什么时候应该用条件断点。碰到一个新的程序，你肯定要在入口Main里面下个断点，这个Main就会分几个枝出来，然后对你感兴趣的枝再设断点(Main中也许就不需要设了)，依次类推。当然，如何用更好的方法调试某个程序，是需要具体问题具体分析的。这需要经验的积累。曾经有2两个3年经验的兄弟问我同一个问题"这个IF为什么不进去？"， 我说只有一种可能就是“IF的条件不满足。”，在IF那设个断点，一个一个条件看。

 

     我也曾阅读过一些源码，如Cindy（一个跟Mina差不多的NIO框架，国人写的），2007年我花了大概一周的晚上，搞清楚了所有细节，然后abbot,一个Java写的自动化测试工具，我研究了一个月，最终肢解并扩展用在我的项目中，还有Mina实现的Ftp,差不多两天就弄清楚了。最近扩展了csvddbc, 增加了cache功能，实现了类似mysql的LIMIT语法。每读一个程序，我都会有收获，"原来这个问题可以这样处理，或是这样处理更好，效率更高"。把别人好的思想装到自己的脑袋了，按老俞的说法，就是"让自己更有价值。"

 

     与其天天记Struct,Spring的配置，还不如了解其思想，当你拥有了足够多的思想时，学习新的框架就会更简单，因为你会觉得"要是是我，我一定会这样处理"，结果作者果然就是如你所然，这其实就是规则一。

 

     对刚进公司的新人也是一样，组长给你一个项目代码，让你自己看，也许有些过时的文档；你会非常头大，组长说"你有问题来问我。"经验告诉我，你其实有问题但是都不知道该怎么问。所以你可以依据以上规则，静下心来，耐心的调试，分析，总结，记得要记笔记。不断的假设、猜想，然后证实、证伪。终于你发现，原来是这样，也没想的那么难。