程式碼閱讀的必要性
   閱讀別人的程式碼作為研發人員是一件經常要做的事情。一個是學習新的程式語言的時候通過閱讀別人的程式碼是個最佳的學習方法，另外是積累程式設計經驗。如果你有機 會閱讀一些作業系統的程式碼會幫助你理解一些基本的原理。更有就是在你作為一個質量確保人員或一個小領導的時候如果你要做白盒測試的時候沒有閱讀程式碼的能力 是不能完成相應的任務。最後一個就是如果你中途接手一個專案的時候或給一個專案做售後服務的時候是要有閱讀程式碼的能力的。

收集所有可能收集的材料
閱 讀程式碼要做的第一件事情是收集所有和專案相關的資料。比如你要做一個專案的售後服務，那麼你首先要搞明白專案做什麼用的，那麼調研檔案、概要設計文 件、周詳設計檔案、測試檔案、使用手冊都是你要最先搞到手的。如果你是為了學習那麼儘量收集和你的學習有關的資料，比如你想學習linux的檔案系統的代 碼，那最佳要找到linux的使用手冊、及檔案系統設計的方法、資料結構的說明。(這些資料在書店裡都能找到)。
　　材料的種類分為幾種型別

1.基礎資料。
比如你閱讀turbo c2的原始碼你要有turbo c2的函式手冊，使用手冊等專業書籍，msc 6.0或java 的話不僅要有函式手冊，還要有類庫函式手冊。這些資料都是你的基礎資料。另外你要有一些關於uml的資料能作為查詢手冊也是個不錯的選擇
2.和程式相關的專業資料。
每 一個程式都是和相關行業相關的。比如我閱讀過一個關於氣象分析方面的程式碼，因為裡邊用到了一個複雜的資料轉換公式，所以不得不把自己的大學時候課本 找出來來複習一下高等數學的內容。如果你想閱讀linux的檔案管理的程式碼，那麼找一本講解linux檔案系統的書對你的幫助會非常大。
3.相關專案的檔案資料
這 一部分的資料分為兩種，一個相關行業的資料，比如你要閱讀一個稅務系統的程式碼那麼有一些財務/稅務系統的專業資料和國家的相關的法律、法規的資料是 必不可少的。此外就是關於這個專案的需求分析報告、概要設計報告、周詳設計報告，使用手冊、測試報告等，儘量多收集對你以後的程式碼閱讀是非常重要的

知識準備
瞭解基礎知識，不要上來就閱讀程式碼，打好基礎能做到事半功倍的效果

留備份,構造可執行的環境
代 碼拿到手之後的第一件事情是先做備份，最佳是刻在一個光碟上，在程式碼閱讀的時候一點不動程式碼是非常困難的一件事情，特別是你要做一些修改性或增強性 維護的時候。而一旦做修改就可能發生問題，到時候要恢復是經常發生的事情，如果你不能非常好的使用版本控制軟體那麼先留一個備份是個最起碼的需求了。
在 做完備份之後最佳給自己構造一個可執行的環境，當然可能會非常麻煩，但可執行程式碼和不可執行的程式碼閱讀起來難度會差非常多的。所以多用一點時間搭建 一個環境是非常值得的，而且我們閱讀程式碼主要是為了修改其中的問題或做移植操作。不能執行的程式碼除了能學到一些技術以外，用處有限。

找開始的地方
做什麼事情都要知道從那裡開始，讀程式也不例外。在c語言裡,首先要找到main()函式，然後逐層去閱讀，其他的程式無論是vb、delphi都要首先找到程式頭，否則你是非常難分析清晰程式的層次關係。

分層次閱讀
在 閱讀程式碼的時候不要一頭就紮下去，這樣往往容易只見樹木不見森林，閱讀程式碼比較好的方法有一點象二叉樹的廣度優先的遍歷。在程式主體一般會比較簡 單，呼叫的函式會比較少，根據函式的名字及層次關係一般能確定每一個函式的大致用途，將你的理解作為註解寫在這些函式的邊上。當然非常難一次就將全部註解 都寫正確，有時候甚至可能是你猜測的結果，不過沒有關係這些註解在閱讀過程是不斷修正的，直到你全部理解了程式碼為止。一般來說採用逐層閱讀的方法能是你係 統的理解保持在一個正確的方向上。避免一下子扎入到細節的問題上。在分層次閱讀的時候要注意一個問題，就是將系統的函式和研發人員編寫程式碼區分開。在c, c++，java ,delphi中都有自己的系統函式，不要去閱讀這些系統函式，除非你要學習他們的程式設計方法，否則只會浪費你的時間。將系統函式表示出來，註明他們的作用 即可，區分系統函式和自編函式有幾個方法，一個是系統函式的程式設計風格一般會比較好，而自編的函式的程式設計風格一般比較會比較差。從變數名、行之間的縮排、注 解等方面一般能分辨出來，另外一個是象ms c6++會在你程式設計的時候給你生成一大堆檔案出來，其中有非常多檔案是你用不到了，能根據檔名來區分一下時候是系統函式，最後如果你實在確定不了，那就 用研發系統的幫助系統去查一下函式名，對一下引數等來確定即可。

寫註解
寫 註解是在閱讀程式碼中最重要的一個步驟，在我們閱讀的原始碼一般來說是我們不熟悉的系統,閱讀別人的程式碼一般會有幾個問題，1搞明白別人的程式設計思想不 是一件非常容易的事情，即使你知道這段程式的思路的時候也是相同。2閱讀程式碼的時候程式碼量一般會比較大，如果不及時寫註解往往會造成讀明白了後邊忘了前邊 的現象。3閱讀程式碼的時候難免會出現理解錯誤，如果沒有及時的寫註解非常難及時的發現這些錯誤。4不寫註解有時候你發生你非常難確定一個函式你時候閱讀 過，他的功能是什麼，經常會發生重複閱讀、理解的現象。
好了，說一些寫註解的基本方法：1猜測的去寫，剛開始閱讀一個程式碼的時候，你非常難一下 子就確定所有的函式的功能，不妨採用採用猜測的方法去寫註解， 根據函式的名字、位置寫一個大致的註解，當然一般會有錯誤，但你的註解實際是不僅調整的，直到最後你理解了全部程式碼。2按功能去寫，別把註解寫成語法說明 書，千萬別看到fopen就寫開啟檔案，看到fread就寫讀資料，這樣的註解一點用處都沒有，而應該寫在此處研發引數設定檔案(****。dat)讀出 系統初始化引數。。。。。，這樣才是有用的註解。3在寫註解的使用另外要注意的一個問題是分清晰系統自動生成的程式碼和使用者自己研發的程式碼，一般來說沒有必 要寫系統自動生成的程式碼。象delphi的程式碼，我們往往要自己編寫一些自己的程式碼段，還要對一些系統自動生成的程式碼段進行修改，這些程式碼在閱讀過程是要 寫註解的，但有一些沒有修改過的自動生成的程式碼就沒有必要寫註解了。4在主要程式碼段要寫較為周詳的註解。有一些函式或類在程式中起關鍵的作用，那麼要寫比 較周詳的註解。這樣對你理解程式碼有非常大的幫助。5對你理解起來比較困難的地方要寫周詳的註解，在這些地方往往會有一些程式設計的技巧。不理解這些程式設計技巧對 你以後的理解或移植會有問題。6寫中文註解。如果你的英文足夠的好，不用看這條了，但非常多的人英文實在不怎麼樣，那就寫中文註解吧，我們寫註解是為了加 快自己的理解速度。中文在大多數的時候比英文更適應中國人。和其寫一些誰也看不懂的英文註解還不如不寫。

重複閱讀
一 次就能將所有的程式碼都閱讀明白的人是沒有的。至少我還沒有遇見過。反覆的去閱讀同一段程式碼有助於得程式碼的理解。一般來說，在第一次閱讀程式碼的時候你 能跳過非常多一時不明白的程式碼段，只寫一些簡單的註解，在以後的重複閱讀過程用，你對程式碼的理解會比上一次理解的更深刻，這樣你能修改那些註解錯誤的地方 和上一次沒有理解的對方。一般來說，對程式碼閱讀3，4次基本能理解程式碼的含義和作用。

執行並修改程式碼
如果你的程式碼是可執行的，那麼先讓他執行起來，用單步跟蹤的方法來閱讀程式碼，會提高你的程式碼速度。程式碼通過看中間變量了解程式碼的含義,而且對 以後的修改會提供非常大的幫助
用自己的程式碼代替原有程式碼，看效果，但在之前要保留原始碼
600行的一個函式，閱讀起來非常困難，程式設計的人不是個好的習慣。在閱讀這個程式碼的時候將程式碼進行修改，變成了14個函式。每一個大約是40-50 行左右。