如何看懂源代碼--(分析源代碼方法)

       想要更多軟體開發資料或幫助， 請加QQ技術群： 69255833

________________________________________

       我們在寫程式時，有不少時間都是在看别人的代碼。

       例如看小組的代碼，看小組整合的守則，若一開始沒規劃怎麼看，就會出問題。

不管是參考也好，從開源抓下來研究也好，為了了解箇中含意，在有限的時間下，不免會對龐大的源代碼解讀感到壓力。

網絡上上有一篇關于分析看代碼的方法，做為程式設計師的您，不妨參考看看，

換個角度來分析。 也能更有效率的解讀你想要的程式碼片段。

六個章節：

（ 1 ）讀懂程式碼，使心法皆為我所用。

（ 2 ）摸清架構，便可輕松掌握全貌。

（ 3 ）優質工具在手，讀懂程式非難事。

（ 4 ）望文生義，進而推敲元件的作用。

（ 5 ）找到程式入口，再由上而下抽絲剝繭。

（ 6 ）閱讀的樂趣，透過程式碼認識作者。

       閱讀他人的程式碼（ 1 ）——讀懂程式碼，使心法皆為我所用

      程式碼是别人寫的，隻有原作者才真的了解程式碼的用途及涵義。許多程式人心裡都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程式碼。但是，與其抗拒接收别人的程式碼，不如徹底了解相關的語言和慣例，當成是培養自我實力的基石。

     1. 消除人類内心深處對于陌生事物的原始恐懼。

     2. 讀懂别人寫的程式碼，讓你收獲滿滿。——在現今開放原始碼的風氣如此盛行的今日，你可以透過開放原始碼學習到新的技術，學習到高手的架構設計，大幅提高學習的效率及效果。你甚至可以直接自開放原始碼專案中抽取，提煉出自己所需的程式碼，站在巨人的肩膀上，直接由彼端獲得所需的生産力。從這個觀點來看，讀懂别人所寫的程式碼，就不再隻是從負面觀點的“被迫接收”，而是極具正面價值的“汲取養份。”

    3. 先了解系統架構與行為模式，再細讀。——接觸他人的程式碼，大緻上可以分為三種程度：一，了解，二，修改，擴充，三，抽取，提煉。了解别人的程式碼是最基礎的工作，倘若不能了解自己要處理的程式碼，就甭論修改或擴充，更不可能去蕪存菁，從中萃取出自己所需，回收再利用别人所撰寫的程式碼。

是以，閱讀程式碼的重點，不在于讀完每一行程式碼，而是在于有效率地透過探索及閱讀，進而了解系統的架構及行為模式。以便在你需要了解任何片段的細節實作時，能夠很快在腦上對映到具體的程式碼位置，直到那一刻，才是細讀的時機。

    4. 熟悉溝通語言與慣例用語（即命名規範）——不論如何，有些基本的準備，是閱讀他人程式碼時必須要有的。

    5. 掌握程式碼撰寫者的心态與習慣——想要閱讀程式碼，得先試着體會程式碼作者的“心”。想要這麼做，就得多了解對方所使用的語言，以及慣常運用的語彙。

閱讀他人的程式碼（ 2 ） -摸清架構，便可輕松掌握全貌

       在本文中，我們的重點放在：要了解一個系統，最好是采取由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，因為那通常對于你了解全貌，沒有多大的幫助。閱讀程式碼不需要從第一行讀起，我們的目的并不是在于讀遍每一段程式碼。

      1.由上而下厘清架構後，便可輕易了解組成關系。

      2.了解架構，必須要加上層次感;——事件産生器産生事件，并送至事件分派器，而事件分派器負責找出各事件相對應的事件處理器，并且轉交該事件，并指令事件處理器加以處理。像的圖形使用者界面的Windows應用程式，便是采用事件驅動式的架構。

      3.探索架構的第一件事：找出系統如何初始化。——有經驗的程式人，對于時常被運用的架構都很熟悉。常常隻需要瞧上幾眼，就能明白一個系統所用的架構，自然就能夠直接聯想到其中會存在的角色，以及角色間的關系。然而，并不是每個系統所用的架構，都是大衆所熟悉，或是一眼能夠望穿的。這時候，你需要探索。目标同樣要放在界定其中的角色，以及角色間的靜态，動态關系。

      4.要了解一個系統，最好是采取由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，因為那通常對于你了解全貌，沒有多大的幫助。

​​

閱讀他人的程式碼（ 3 ） -優質工具在手，讀懂程式非難事

       系統的複雜度往往超過人腦的負荷。閱讀程式碼的時候，你會需要更多工具提供協助。使用好的整合式開發環境（ IDE ）的或文字編輯器，就能提供最基本的幫助。

      因為在閱讀程式碼時，最常做的事，就是随着程式中的某個控制流，将閱讀的重心，從某個函式移至它所呼叫的另一個函式。是以對程式人來說，閱讀程式碼時最常做的事之一就是：找出某個函式位在那一個原始檔裡，接着找到該函式所在的位置。

閱讀他人的程式碼（ 4 ） -望文生義，進而推敲元件的作用

       先建立系統的架構性認識，然後透過名稱及命名慣例，就可以推測出各元件的作用。例如：當AOL的Winamp嘗試着初始化一個插件時，它會呼叫這個結構中的初始化函式，以便讓每個插件程式有機會初始化自己。當AOL的Winamp打算結束自己或結束某個插件的執行時，便會呼叫退出函式。

        在閱讀程式碼的細節之前，我們應先試着捕捉系統的運作情境。在采取由上至下的方式時，系統性的架構是最頂端的層次，而系統的運作情境，則是在它之下的另一個層次。

“望文生義”很重要，我們看到函式的名稱，就可以猜想到它所代表的作用。

閱讀他人的程式碼（ 5 ） -找到函數入口，再由上而下抽絲剝繭

        根據需要決定展開的層數，或展開特定節點，并記錄樹狀結構，然後适度忽略不需要了解的細節─這是一個很重要的态度。因為你不會一次就需要所有的細節，閱讀都是有目的的，每次的閱讀也許都在探索程式中不同的區域。

探索系統架構的第一步，就是找到函數的入口點。找到入口點後，多半采取由上而下（自上而下）的方式，由最外層的結構，一層一層逐漸探索越來越多的細節。

       我們強調一種不同的做法：在閱讀程式代碼時，多半采取由上而下的方式，而本文建議了一種記錄閱讀的方式，就是試着記錄探索追蹤時層層展開的樹狀結構。你可以視自己需要，了解的深入程度，再決定要展開的層數。你更可以依據特殊的需要，隻展開某個特定的節點，以探索特定的細目。

      适度地忽略不需要了解的細節，是一個很重要的态度，因為你不會一次就需要所有的細節，閱讀都是有目的的。每次的閱讀也許都在探索程式中不同的區域;而每次探索時，你都可以增補樹狀結構中的某個子結構。漸漸地，你就會對這個程式更加的了解。

閱讀他人的程式碼（ 6 ） -閱讀的樂趣：透過程式碼認識作者

       即便每個人的寫作模式多半受到他人的影響，程式人通常還是會融合多種風格，而成為自己獨有的特色，如果你知道作者程式設計的偏好，閱讀他的程式碼就更得心應手。

       閱讀程式碼時，多半會采取由上而下，抽絲剝繭的方式。透過記錄層層展開的樹狀結構，程式人可以逐漸地建立起對系統的架構觀，而且可以依照需要的粒度（粒度），決定展開的層次及精緻程度。

       建立架構觀點的認識是最重要的事情。雖然這一系列的文章前提為“閱讀他人的程式碼”，但我們真正想做的工作，并不在于徹底地詳讀每一行程式碼的細節，而是想要透過重點式的程式碼“摘讀” ，達到對系統所需程度的了解。每個人在閱讀程式碼的動機不盡相同，需要了解的程度也就有深淺的分别。隻有極為少數的情況下，你才會需要細讀每一行程式碼。

閱讀程式碼是新時代程式員必備的重要技能。

總結

       當你從視閱讀他人的程式碼為畏途，轉變成為可以從中擷取樂趣的時候，我想，你又進到了另一個境界。

       轉載自（部分删減）

http://www.cnblogs.com/ToDoToTry/archive/2009/06/21/1507760.html