1、最好先看目錄結構並找到配置文件
2、以自己的開發經驗去判斷大概的程序架構，理清楚是否爲單點入口，
3、讓把程序運行起來
沒有數據庫的情況下運行起來可能會錯誤很多，不過這些錯誤可以引導你對程序理解，對着錯誤提示，跟蹤代碼脈絡，很容易就把整個系統拿上手了。
我通常是局部功能研究着手，研究一個功能的走向流程，那麼基本可以熟悉他的基本工作模式來，然後在逐步的推敲框架結構
先看下是否有框架，如果有框架，去看下框架文檔就知道了
如果沒有框架，看是否能出框架的出口和入口入手了
先看下
目錄結構
使用xdebug生成profile文件，可以用KCachegrind來查看，但是這個工具只在linux下面可用，沒有windows下的版本。這裏推薦一個win下的免費工具——wincachegrind，也可以查看xdebug的profile文件，用來分析php代碼運行情況足夠用了（偶爾不太穩定）。
有代碼的流程，大部分的項目就可以知道整個代碼流程了，
具體邏輯的東西，就只能你自己慢慢體會。
奇吧太多了
開源的嗎?
如果有文檔的話 當然是先看文檔了 如果沒有的話就用調試工具吧 比如Zend Studio什麼的
好像沒有快速的方法。我的做法是看着代碼在腦中跑一遍，瞭解大概流程，然後再細看。
如果沒註釋的話很困難，如果有phpDocumenter的標準註釋可以用它來生成文檔
一個源碼首先第一步不看代碼，看結構，大致知道採用的是那種設計模式，例如函數式的還是mvc方式的，接下來從一個功能入手，先用firebug或者chrome的工具查看請求的url,以及請求url後web前端表現出來的，接下來，上面的模式用到了，去看url對於的方法吧，方法中必定會調用其他的方法，層層遞進，分析下來，這個小功能的實現懂了吧，然後多多分析各個功能的實現，大致這個源碼的結構熟悉了，那麼帶着前端的一些操作去摸索各個功能點的實現方法吧
1、拿到代碼查看項目當中是否有readme這樣的文件，如果沒有查看是否有文檔之類的
2、代碼當中沒有文檔，那麼就想你的同事或者其他人要這個框架的介紹或者資料
3、先請教別人這個框架的大體思路
4、自己獨立去按照文檔或者其他人說的思路去看代碼
5、不懂的地方全部記錄下面，一次行去問，有的時候很多問題在你看到後面的東西的時候就自然明白了
6、看懂了代碼之後自己嘗試着寫一個，看自己的理解是否正確就這麼多了。
先了解整體流程,在個個擊破~!
第一章:
導論
++++++++++++
1.要養成一個習慣, 經常花時間閱讀別人編寫的高品質代碼.
2.要有選擇地閱讀代碼, 同時, 還要有自己的目標. 您是想學習新的模式|編碼風格|還是滿足某些需求的方法.
3.要注意並重視代碼中特殊的非功能性需求, 這些需求也許會導致特殊的實現風格.
4.在現有的代碼上工作時, 請與作者和維護人員進行必要的協調, 以避免重複勞動或產生厭惡情緒.
5.請將從開放源碼軟件中得到的益處看作是一項貸款, 儘可能地尋找各種方式來回報開放源碼社團.
6.多數情況下, 如果您想要了解"別人會如何完成這個功能呢?", 除了閱讀代碼以外, 沒有更好的方法.
7.在尋找bug時, 請從問題的表現形式到問題的根源來分析代碼. 不要沿着不相關的路徑(誤入歧途).
8.我們要充分利用調試器|編譯器給出的警告或輸出的符號代碼|系統調用跟蹤器|數據庫結構化查詢語言的日誌機制|包轉儲工具和Windows的消息偵查程序, 定出的bug的位置.
9.對於那些大型且組織良好的系統, 您只需要最低限度地瞭解它的全部功能, 就能夠對它做出修改.
10.當向系統中增加新功能時, 首先的任務就是找到實現類似特性的代碼, 將它作爲待實現功能的模板.
11.從特性的功能描述到代碼的實現, 可以按照字符串消息, 或使用關鍵詞來搜索代碼.
12.在移植代碼或修改接口時, 您可以通過編譯器直接定位出問題涉及的範圍, 從而減少代碼閱讀的工作量.
13.進行重構時, 您從一個能夠正常工作的系統開始做起, 希望確保結束時系統能夠正常工作. 一套恰當的測試用例(test case)可以幫助您滿足此項約束.
14.閱讀代碼尋找重構機會時, 先從系統的構架開始, 然後逐步細化, 能夠獲得最大的效益.
15.代碼的可重用性是一個很誘人, 但難以理解與分離, 可以試着尋找粒度更大一些的包, 甚至其他代碼.
16.在複查軟件系統時, 要注意, 系統是由很多部分組成的, 不僅僅只是執行語句. 還要注意分析以下內容: 文件和目錄結構|生成和配置過程|
用戶界面和系統的文檔.
18.可以將軟件複查作爲一個學習|講授|援之以手和接受幫助的機會.
++++++++++++++++++++
第二章: 基本編程元素
++++++++++++++++++++
19.第一次分析一個程序時, main是一個好的起始點.
20.層疊if-else if-...-else序列可以看作是由互斥選擇項組成的選擇結構.
21.有時, 要想了解程序在某一方面的功能, 運行它可能比閱讀源代碼更爲恰當.
22.在分析重要的程序時, 最好首先識別出重要的組成部分.
23.瞭解局部的命名約定, 利用它們來猜測變量和函數的功能用途.
24.當基於猜測修改代碼時, 您應該設計能夠驗證最初假設的過程. 這個過程可能包括用編譯器進行檢查|引入斷言|或者執行適當的測試用例.
25.理解了代碼的某一部分, 可能幫助你理解餘下的代碼.
26.解決困難的代碼要從容易的部分入手.
27.要養成遇到庫元素就去閱讀相關文檔的習慣; 這將會增強您閱讀和編寫代碼的能力.
28.代碼閱讀有許多可選擇的策略: 自底向上和自頂向下的分析|應用試探法和檢查註釋和外部文檔, 應該依據問題的需要嘗試所有這些方法.
29.for (i=0; i<n; i++)形式的循環執行n次; 其他任何形式都要小心.
30.涉及兩項不等測試(其中一項包括相等條件)的比較表達式可以看作是區間成員測試.
31.我們經常可以將表達式應用在樣本數據上, 藉以瞭解它的含義.
32.使用De Morgan法則簡化複雜的邏輯表達式.
33.在閱讀邏輯乘表達式時, 問題可以認爲正在分析的表達式以左的表達式均爲true; 在閱讀邏輯和表達式時, 類似地, 可以認爲正在分析的表達式以左的表達式均爲false.
34.重新組織您控制的代碼, 使之更爲易讀.
35.將使用條件運行符? :的表達式理解爲if代碼.
36.不需要爲了效率, 犧牲代碼的易讀性.
37.高效的算法和特殊的優化確實有可能使得代碼更爲複雜, 從而更難理解, 但這並不意味着使代碼更爲緊湊和不易讀會提高它的效率.
38.創造性的代碼佈局可以用來提高代碼的易讀性.
39.我們可以使用空格|臨時變量和括號提高表達式的易讀性.
40.在閱讀您所控制的代碼時, 要養成添加註釋的習慣.
41.我們可以用好的縮進以及對變量名稱的明智選擇, 提高編寫欠佳的程序的易讀性.
42.用diff程序分析程序的修訂歷史時, 如果這段歷史跨越了整體重新縮排, 常常可以通過指定-w選項, 讓diff忽略空白差異, 避免由於更改了縮進層次而引入的噪音.
43.do循環的循環體至少執行一次.
44.執行算術運算時, 當b=2n-1時, 可以將a&b理解爲a%(b+1).
45.將a<<n理解爲a*k, k=2n.
46.將a>>n理解爲a/k, k=2n.
47.每次只分析一個控制結構, 將它的內容看作是一個黑盒.
48.將每個控制結構的控制表達式看作是它所包含代碼的斷言.
49.return, goto, break和continue語句, 還有異常, 都會影響結構化的執行流程. 由於這些語句一般都會終止或重新開始正在進行的循環,
因此要單獨推理它們的行爲.
50.用複雜循環的變式和不變式, 對循環進行推理.
51.使用保持含義不變的變換重新安排代碼, 簡化代碼的推理工作.
++++++++++++
1.要養成一個習慣, 經常花時間閱讀別人編寫的高品質代碼.
2.要有選擇地閱讀代碼, 同時, 還要有自己的目標. 您是想學習新的模式|編碼風格|還是滿足某些需求的方法.
3.要注意並重視代碼中特殊的非功能性需求, 這些需求也許會導致特殊的實現風格.
4.在現有的代碼上工作時, 請與作者和維護人員進行必要的協調, 以避免重複勞動或產生厭惡情緒.
5.請將從開放源碼軟件中得到的益處看作是一項貸款, 儘可能地尋找各種方式來回報開放源碼社團.
6.多數情況下, 如果您想要了解"別人會如何完成這個功能呢?", 除了閱讀代碼以外, 沒有更好的方法.
7.在尋找bug時, 請從問題的表現形式到問題的根源來分析代碼. 不要沿着不相關的路徑(誤入歧途).
8.我們要充分利用調試器|編譯器給出的警告或輸出的符號代碼|系統調用跟蹤器|數據庫結構化查詢語言的日誌機制|包轉儲工具和Windows的消息偵查程序, 定出的bug的位置.
9.對於那些大型且組織良好的系統, 您只需要最低限度地瞭解它的全部功能, 就能夠對它做出修改.
10.當向系統中增加新功能時, 首先的任務就是找到實現類似特性的代碼, 將它作爲待實現功能的模板.
11.從特性的功能描述到代碼的實現, 可以按照字符串消息, 或使用關鍵詞來搜索代碼.
12.在移植代碼或修改接口時, 您可以通過編譯器直接定位出問題涉及的範圍, 從而減少代碼閱讀的工作量.
13.進行重構時, 您從一個能夠正常工作的系統開始做起, 希望確保結束時系統能夠正常工作. 一套恰當的測試用例(test case)可以幫助您滿足此項約束.
14.閱讀代碼尋找重構機會時, 先從系統的構架開始, 然後逐步細化, 能夠獲得最大的效益.
15.代碼的可重用性是一個很誘人, 但難以理解與分離, 可以試着尋找粒度更大一些的包, 甚至其他代碼.
16.在複查軟件系統時, 要注意, 系統是由很多部分組成的, 不僅僅只是執行語句. 還要注意分析以下內容: 文件和目錄結構|生成和配置過程|
用戶界面和系統的文檔.
18.可以將軟件複查作爲一個學習|講授|援之以手和接受幫助的機會.
++++++++++++++++++++
第二章: 基本編程元素
++++++++++++++++++++
19.第一次分析一個程序時, main是一個好的起始點.
20.層疊if-else if-...-else序列可以看作是由互斥選擇項組成的選擇結構.
21.有時, 要想了解程序在某一方面的功能, 運行它可能比閱讀源代碼更爲恰當.
22.在分析重要的程序時, 最好首先識別出重要的組成部分.
23.瞭解局部的命名約定, 利用它們來猜測變量和函數的功能用途.
24.當基於猜測修改代碼時, 您應該設計能夠驗證最初假設的過程. 這個過程可能包括用編譯器進行檢查|引入斷言|或者執行適當的測試用例.
25.理解了代碼的某一部分, 可能幫助你理解餘下的代碼.
26.解決困難的代碼要從容易的部分入手.
27.要養成遇到庫元素就去閱讀相關文檔的習慣; 這將會增強您閱讀和編寫代碼的能力.
28.代碼閱讀有許多可選擇的策略: 自底向上和自頂向下的分析|應用試探法和檢查註釋和外部文檔, 應該依據問題的需要嘗試所有這些方法.
29.for (i=0; i<n; i++)形式的循環執行n次; 其他任何形式都要小心.
30.涉及兩項不等測試(其中一項包括相等條件)的比較表達式可以看作是區間成員測試.
31.我們經常可以將表達式應用在樣本數據上, 藉以瞭解它的含義.
32.使用De Morgan法則簡化複雜的邏輯表達式.
33.在閱讀邏輯乘表達式時, 問題可以認爲正在分析的表達式以左的表達式均爲true; 在閱讀邏輯和表達式時, 類似地, 可以認爲正在分析的表達式以左的表達式均爲false.
34.重新組織您控制的代碼, 使之更爲易讀.
35.將使用條件運行符? :的表達式理解爲if代碼.
36.不需要爲了效率, 犧牲代碼的易讀性.
37.高效的算法和特殊的優化確實有可能使得代碼更爲複雜, 從而更難理解, 但這並不意味着使代碼更爲緊湊和不易讀會提高它的效率.
38.創造性的代碼佈局可以用來提高代碼的易讀性.
39.我們可以使用空格|臨時變量和括號提高表達式的易讀性.
40.在閱讀您所控制的代碼時, 要養成添加註釋的習慣.
41.我們可以用好的縮進以及對變量名稱的明智選擇, 提高編寫欠佳的程序的易讀性.
42.用diff程序分析程序的修訂歷史時, 如果這段歷史跨越了整體重新縮排, 常常可以通過指定-w選項, 讓diff忽略空白差異, 避免由於更改了縮進層次而引入的噪音.
43.do循環的循環體至少執行一次.
44.執行算術運算時, 當b=2n-1時, 可以將a&b理解爲a%(b+1).
45.將a<<n理解爲a*k, k=2n.
46.將a>>n理解爲a/k, k=2n.
47.每次只分析一個控制結構, 將它的內容看作是一個黑盒.
48.將每個控制結構的控制表達式看作是它所包含代碼的斷言.
49.return, goto, break和continue語句, 還有異常, 都會影響結構化的執行流程. 由於這些語句一般都會終止或重新開始正在進行的循環,
因此要單獨推理它們的行爲.
50.用複雜循環的變式和不變式, 對循環進行推理.
51.使用保持含義不變的變換重新安排代碼, 簡化代碼的推理工作.
全文均爲轉載
從各個帖子，博文裏
有來源於知乎帖的
最後這段轉自jk110333的文章