眾所周知，要想寫出好的程序，除了要經常寫之外，還有看看別人是怎么寫的，所以讀別人的程序是非常重要的；如今是個信息交換十分發達的時代，你可以輕易的就看到頂尖級選手的代碼；開源事業蒸蒸日上，確實是所有程序員的福音。但如何閱讀別人的代碼呢？尤其對於初學者而言，確實是個難題，就像碰到一漂亮的刺蝟，實在不知道如何下嘴。
規則一，
你讀的越多，你就越容易讀懂，因為高手寫程序的思維都是趨同的，正所謂萬劍歸宗；當然你要找到這個“同”，是需要功力的。設計模式是“同”之一，一般碰到同類型問題，大家都傾向於用同樣的“模式”處理，所以你了解了這種模式，下次你看某個源程序時，其中有類似問題，你肯定就會想到作者很可能是用這種模式處理的。這樣你就會更容易看清作者的思路，理清程序的脈絡。
規則二，
由上之下，逐步求精。不要一開始就想把所有的細節搞清楚，否則你就會陷入“只見樹木，不見森林”的困境。先要理清程序的脈絡，知道那個包是干什么的，那個類是干什么的，他們之間有什么樣的聯系。然后在一個一個問題深究。其思想就是，大而化下，再大而化小...你要細到什么程度，取決於你的要求及期望。一般我看到包，類一層就不會看了，除非我對某個算法感興趣，我也會仔細在研究之。其實這也是面向對象的設計思想，由上至下，而不是由下至上。無論你看到哪一層，你都可以說“我了解這個框架的實現”，只是看到的粒度不同而已。
規則三，
調試。我認為調試程序員最重要的功底，而不是最重要的之一。斷點下在哪里最有可能定位問題所在，但又不浪費時間，記住斷點並不是越多越好。什么時候應該用條件斷點。碰到一個新的程序，你肯定要在入口Main里面下個斷點，這個Main就會分幾個枝出來，然后對你感興趣的枝再設斷點(Main中也許就不需要設了)，依次類推。當然，如何用更好的方法調試某個程序，是需要具體問題具體分析的。這需要經驗的積累。曾經有2兩個3年經驗的兄弟問我同一個問題"這個IF為什么不進去？"， 我說只有一種可能就是“IF的條件不滿足。”，在IF那設個斷點，一個一個條件看。
我也曾閱讀過一些源碼，如Cindy（一個跟Mina差不多的NIO框架，國人寫的），2007年我花了大概一周的晚上，搞清楚了所有細節，然后abbot,一個Java寫的自動化測試工具，我研究了一個月，最終肢解並擴展用在我的項目中，還有Mina實現的Ftp,差不多兩天就弄清楚了。最近擴展了csvddbc, 增加了cache功能，實現了類似mysql的LIMIT語法。每讀一個程序，我都會有收獲，"原來這個問題可以這樣處理，或是這樣處理更好，效率更高"。把別人好的思想裝到自己的腦袋了，按老俞的說法，就是"讓自己更有價值。"
與其天天記Struct,Spring的配置，還不如了解其思想，當你擁有了足夠多的思想時，學習新的框架就會更簡單，因為你會覺得"要是是我，我一定會這樣處理"，結果作者果然就是如你所然，這其實就是規則一。
對剛進公司的新人也是一樣，組長給你一個項目代碼，讓你自己看，也許有些過時的文檔；你會非常頭大，組長說"你有問題來問我。"經驗告訴我，你其實有問題但是都不知道該怎么問。所以你可以依據以上規則，靜下心來，耐心的調試，分析，總結，記得要記筆記。不斷的假設、猜想，然后證實、證偽。終於你發現，原來是這樣，也沒想的那么難