一.為什麼要閱讀程式碼

  養成閱讀高品質程式碼的習慣，可以提高編寫程式碼的能力。

  電腦科學是一門實踐性很強的學科，很多內容在書本上根本學不到。就拿專案的組織來說，沒有什麼書籍專門論述應該如何組織與管理專案的目錄結構，因為這本身就是一種見仁見智的活動，要受到各種因素的影響。程式碼中往往凝聚著許多實踐性的知識，通過閱讀程式碼才能真正掌握軟體開發的真諦。我們可以將“書籍是人類進步的階梯”，擴充套件為”一切承載人類知識的載體，都是人類進步的階梯。

  我曾向一個資深的開發人員詢問過，應該如何提高資深的開發與設計能力，他的回答是，廣泛的閱讀一些現有的框架，比如Apple的開發框架、borland的OWL和Delphi、smalltalk、MFC等，瞭解他們是如何組織的，電腦科學是這樣一門學科，入門十分容易，不需要深奧的教學知識，也沒有複雜的物理模型，但要想提高卻很難，真正能夠叱吒風雲，引領潮流的人卻少之又少，這就有如人生，在蹣跚學步之時，主要的精力都要放在看腳下的路面上，注意路上的坎坷和荊棘，隨著年齡的增長，當走路越來越穩健時，卻迷失了方向，不知道應該走向何方，這個時候腳下的路已經不再重要，你需要從先哲們留下的隻字片語，別人走過的”路”汲取靈感，確定自己的方向。

  因為，學習編寫偉大程式碼的方式是閱讀程式碼，閱讀大量的程式碼，高品質的程式碼、低品質的程式碼、組合語言程式碼、haskell程式碼、千里之外的陌生人所寫的程式碼以及我們自己上週剛剛編寫的程式碼，因為，如果不這樣，我們就會不斷的重做別人已經完成的工作，重複過去已經發生過的成功和錯誤。

  恐怕沒有那個偉大的小說家從未讀過其他人的著作，沒有哪個偉大的畫家從未研究過他人的作品，沒有哪個技術熟練的外科醫生從未觀察過同時如何動手術，沒有哪個播音747的機長不是首先在副駕駛的位置上觀看如何實際操作的。

  可是我們卻期望程式設計師能夠做到這些（即，不用讀他人的程式碼就能夠編寫出優秀的程式碼），”本週的任務是編寫……”。我麼告訴開發人員語法和構造規則，之後，我們希望他們能夠編寫出相當於偉大小說的軟體。

  具有諷刺意味的是，對閱讀程式碼來說，從來沒有過比現在更好的時光。感謝開放原始碼社團所作出的巨大貢獻，現在網路上有有數以千兆的原始碼，等待我們去閱讀。選定任何一種語言，你就能夠找到原始碼，選擇一個問題域，也存在大量的原始碼。選擇一個級別，從微碼到高階的商業功能，您都能夠找到大量的原始碼。

  要養成一個習慣，經常花時間閱讀別人編寫的高品質程式碼。就像閱讀高品質的散文能夠豐富詞彙、激發想象力、擴充套件思維一樣，分析設計良好的軟體系統的內部結構可以學到新的架構模式、資料結構、編碼方法、演算法、風格和文件規範、應用車需程式設計介面（API），甚至新的計算機語言。閱讀高品質的程式碼還可以提高您編寫程式碼的水準。

  閱讀程式碼的過程中，不可避免的會遇到一些在實踐中應該儘量避免的程式碼。能夠快速的從壞程式碼中區分出好程式碼是一項有價值的技能；接觸一些編碼的反面例子可能有助於您提高這種能力。通過下面這些徵兆，可以容易的識別出低品質的程式碼。

• 編碼風格不一致；
• 結構不必要的複雜或難以理解；
• 明顯的邏輯錯誤或疏忽；
• 過度使用不可移植的構造；
• 缺乏維護；

  然而，不應該期望能夠從編寫品質低下的程式碼中學習到如何正確的程式設計（看來愛迪生實驗燈絲失敗時採取的態度在閱讀程式碼中是不可取的）；如果將這樣的程式碼作為文獻來讀，則是在浪費時間，尤其是考慮到現在能夠訪問到的高品質程式碼的數量。

  請回答這個問題：我正在閱讀的程式碼真的是最好的嗎？開發原始碼運動的優點之一就是，成功的軟體專案和想法激勵競爭者不斷的改進他們的結構和功能。我們常常有幸看到對軟體設計的第二次或第三次重複；大多數情況下（但不總是如此）後面的設計要比先前的版本有顯著的提高。根據您正在尋找的功能，使用相關的關鍵詞，在web上搜索，可以容易的找到各種互相競爭的實現。

  要有選擇的閱讀程式碼，同時，還要有自己的目標。您是想學習新的模式、編碼風格、還是滿足某些需求的方法？或者，您也許只是在瀏覽程式碼，獲得其中的某些亮點。在這種情況下，要隨時準備仔細的研究那些有趣但尚不瞭解的部分，語言特性（即使您對一種語言瞭解的很透徹，也不可能盡知它的所有特性，因為現代語言的發展離不開新特性，新的特性總是不斷湧向）、API、演算法、資料結構、架構和設計模式。

二.什麼時候需要去閱讀程式碼

1.修復bug
2.大多數情況下，您閱讀程式碼不是為了修復一個bug，而是為了增加新的功能、修改現存的特性、改編程式碼使之適應新的環境和需求，或者重構它們來增強程式碼的非功能性品質。

不同的時候閱讀原始碼採用的方法策略是不一樣的，比如情況2，你只需要最小化閱讀即可。不必拘泥於下面的一套流程。以下的內容可以拆開來使用，也可以合在一起使用。選擇你需要的。下面的流程更多是一種自上而下的閱讀方式，當然你也可以採用自底向上的閱讀方式，可以先去了解某一塊細節，然後在決定了解整體架構。

3.提取重用程式碼。