越是結構好的代碼，如果不理解它的思想越是難得看懂，例如Qt、Agg、CryptPP等。這裏我將我的壹些經驗寫在這裏，留個記錄吧。
完善的開源工程都會有文檔，即使沒有文檔也應當有api-guid，那麽我們先找到它們，這時我們不要管它是怎麽設計的，先編譯壹個，照著例子寫個程序運行壹下吧，再試試壹些高級功能。這時我們在心中先猜猜它應當是怎樣設計的（大多數情況是沒有想法）。好吧，我們再來看文檔，文檔中壹般有靜態結構的說明，如模塊劃分、類列表、每個類的成員列表。嗯，還是壹頭霧水啊，沒辦法，我們打開源碼所在的文件夾，看看源碼的組織方式。嗯，有點頭緒了，大多數情況下，目錄結構與工程結構是壹致的，而我們編寫例子程序的時候使用的接口壹般在源碼的include目錄下。那好吧，我們根據頭文件名和目錄結構去找相應的實現文件吧，但這往往相當困難，因為妳會發現它根本就不是妳所想的那樣。壹個類或壹個外部變量，妳想找到它往往會動用Windows的搜索。看了幾個小時還沒有太大的進展，仍然不知道它的頭（高層的入口）在哪，尾（底層的具體實現）在哪，不過妳至少對那些地方有哪些文件都熟悉了，那些零星的註釋也被妳看了壹遍。這時該把妳寫的例子程序拿出來了，我們單步跟進去，跟的同時我們也註意壹下所跟到的文件的物理位置、它附近都有哪些文件、哪些類或結構。壹直跟下去，這樣我們往往會順藤摸瓜找到最底層的實現，並發現壹條執行路徑（太變態的或用了壹堆模板的除外）。由於妳已經對工程的結構有了壹定了解，這時妳可以從頭和尾壹起開始看代碼（前提是妳已經找到了壹個頭和壹個尾），將壹條線弄清楚，那麽這個工程的其他線也應該是差不多的設計思路。
有些開源工程裏面的宏特別多，那妳要當心，首先搞清楚這些宏吧。
用C寫的工程往往比用C++寫的容易懂，因為它最多有很多函數指針和extern變量，而後者則令人頭疼得多，如果妳實在沒有辦法，那麽上網搜吧，很多著名的開源工程壹般會有壹些人將其研究心得放到blog上，看壹看，說不定壹下豁然開朗。
好吧，就寫這麽多，真是亂七八糟。