[轉]如何看懂源代碼

時間 2019-11-24

標籤如何看懂源代碼简体版

原文原文鏈接

咱們在寫程式時，有很多時間都是在看別人的代碼。
例如看小組的代碼，看小組整合的守則，若一開始沒規劃怎麼看，
就會「嚕看嚕苦（臺語）」

無論是參考也好，從開源抓下來研究也好，爲了瞭解箇中含意，在有限的時間下，難免會對龐大的源代碼解讀感到壓力。
網路上有一篇關於分析看代碼的方法，作爲程式設計師的您，不妨參考看看，
換個角度來分析。也能更有效率的解讀你想要的程式碼片斷。

六個章節：
（ 1 ）讀懂程式碼，使心法皆爲我所用。
（ 2 ）摸清架構，即可輕鬆掌握全貌。
（ 3 ）優質工具在手，讀懂程式非難事。
（ 4 ）望文生義，進而推敲組件的做用。
（ 5 ）找到程式入口，再由上而下抽絲剝繭。
（ 6 ）閱讀的樂趣，透過程式碼認識做者。

html

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

程式碼是別人寫的，只有原做者才真的瞭解程式碼的用途及涵義。許多程式人內心都有一種不自覺的恐懼感，深怕被迫去碰觸其餘人所寫的程式碼。可是，與其抗拒接收別人的程式碼，不如完全瞭解相關的語言和慣例，當成是培養自我實力的基石。數據庫

對大多數的程式人來講，撰寫程式碼或許是使人開心的一件事情，但我相信，有更多人視閱讀他人所寫成的程式碼爲畏途。許多人寧肯本身從新寫過一遍程式碼，也不肯意接收別人的程式碼，進而修正錯誤，維護它們，甚至增強功能。

這其中的關鍵究竟在何處呢？如果一語道破，其實也很簡單，程式碼是別人寫的，只有原做者才真的瞭解程式碼的用途及涵義。許多程式人內心都有一種不自覺的恐懼感，深怕被迫去碰觸其餘人所寫的程式碼。這是來自於人類心裏深處對於陌生事物的原始恐懼。

讀懂別人寫的程式碼，讓你收穫滿滿
不過，基於許多現實的緣由，程式人時常受迫要去接收別人的程式碼。例如，同事離職了，必須接手他遺留下來的工做，也有可能你是剛進部門的菜鳥，而同事經驗值夠了，升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的專案，必須接手或是整合客戶前一個廠商所遺留下來的系統，大家手上只有那套系統的原始碼（運氣好時，還有數量不等的文件）。

諸如此類的故事，其實時常在程式人身邊或身上持續上演着。許多程式人都將接手他人的程式碼，當作一件悲慘的事情。每一個人都不想接手別人所撰寫的程式碼，由於不想花時間去探索，寧肯將生產力花在產生新的程式碼，而不是耗費在瞭解這些程式碼上。

很遺憾的是，上述的狀況對程式人來講很難避免。咱們老是必須碰觸到其餘人所寫成的程式碼，甚至必須瞭解它，加以修改。對於這項需求，在現今開放原始碼的風氣如此盛行的今日，正如以前的「程式設計2.0 」文中所提到的，你能夠透過開放原始碼學習到新的技術，學習到高手的架構設計，大幅提升學習的效率及效果。你甚至能夠直接自開放原始碼專案中抽取，提煉出本身所需的程式碼，站在巨人的肩膀上，直接由彼端得到所需的生產力。從這個觀點來看，讀懂別人所寫的程式碼，就再也不只是從負面觀點的「被迫接收」，而是極具正面價值的「汲取養份。」

先了解系統架構與行爲模式，再細讀
假若撰寫程式碼是程式人的重要技藝之一，那麼讀懂別人的程式碼，接着加以修改，也勢必是另外一個重要的技藝。

若是你不能熟悉這項工做，不只在遭逢你所不肯面對的局面時，沒法解決眼前接手他人程式碼的難題，更重要的是，當你看着眼前現成的程式碼，殊不知如何從中擷取本身所需，致使最後只能入寶山空手回，望之興嘆。

接觸他人的程式碼，大體上能夠分爲三種程度：一，瞭解，二，修改，擴充，三，抽取，提煉。瞭解別人的程式碼是最基礎的工做，假若不能瞭解本身要處理的程式碼，就甭論修改或擴充，更不可能去蕪存菁，從中萃取出本身所需，回收再利用別人所撰寫的程式碼。雖然說是「閱讀」，但程式碼並不像文章或小說同樣，透過這種作法，便可以得到必定程度的瞭解。閱讀文章或小說時，幾乎都是循序地閱讀，你只消翻開第一頁，一行行閱讀下去便可。可是，有許多程式人在試着閱讀其餘人的程式碼時，卻每每有不知如何讀起的困難。

或許找到系統的第一頁（也就是程式碼執行的啓始點）並不難，可是複雜度高的系統，有時十分龐大，有時千頭萬緒。

從程式碼的啓始點開始讀起，一來要循序讀完全部的程式碼曠日費時，二來透過這種方式來了解系統，很難在腦中構建出系統的面貌，進而瞭解到系統真正的行爲。因此，閱讀程式碼的重點，不在於讀完每一行程式碼，而是在於有效率地透過探索及閱讀，從而瞭解系統的架構及行爲模式。以便在你須要瞭解任何片斷的細節實做時，可以很快在腦上對映到具體的程式碼位置，直到那一刻，纔是細讀的時機。

熟悉溝通語言與慣例用語
不論如何，有些基本的準備，是閱讀他人程式碼時必需要有的。

首先，你最好得了解程式碼寫成的程式語言。想要讀懂法文寫成的小說，總不能連法文都不懂吧。有些狀況則很特殊。咱們雖然不懂該程式碼撰寫所用的語言，可是由於現代語言的高階化，並且流行的程式語言多半都是血統相近，因此即便不那麼熟悉，有時也可勉力爲之。

除了認識所用語言以外，再來就是要先確認程式碼所用的命名慣例（命名慣例）。瞭解命名慣例很重要，不一樣的程式人或開發團隊，差別可能很大。
這命名慣例涵蓋的範圍一般包括了變數的名稱，函式的名稱，類別（若是是物件導向的話）的名稱，原始碼檔案，甚至是專案建構目錄的名稱。假若使用了像設計模式之類的方法，這些名稱更有一些具體的表述方式。

命名慣例有點像是程式人在程式語言之上，另行建構的一組溝通行話。程式人會透過共通約束，遵照的命名慣例，來表達一些較高階的概念。例如，有名的匈牙利式命名法，便將變數名稱以屬性，型別，說明合併在一塊兒描述。對程式人來講，這種方式可以提供更豐富的資訊，以瞭解該變數的做用及性質。

對程式碼閱讀來講，熟悉這個作法之因此重要，是由於當你瞭解整個系統所採用的慣例時，你便能試着以他們所共同操用的語彙來進行理解。假若，不能瞭解其所用的慣例，那麼這些額外提供的資訊，就沒法爲你所用。像以設計模式寫成的程式碼，一樣到處充滿着模式的名稱，諸如：工廠，門面，代理等等。以這些名稱指涉的類別，也直接透過名稱，表達了它們自身的做用。對於懂得這命名慣例的讀者來講，不須要深刻探索，也能很快捕捉到這些類別的意義。

當你拿到一套必須閱讀的程式碼時，最好先取得命名慣例的說明文件。然而，並非每套程式碼都附有此類的說明文件。另外一個方式，就是本身到程式碼中，大略瀏覽一遍，有經驗的程式人能夠輕易發掘出該系統所用的命名慣例。

常見的命名方式不脫那幾類，這時候經驗就很重要，假若你知道的慣例越多，就越能輕易識別他人所用的慣例。若是運氣很糟，程式碼所用的慣例是前所未見的，那麼你也得花點時間概括，憑本身的力量找出這程式碼命名上的規則。

掌握程式碼撰寫者的心態與習慣
大多數的程式碼，基本上都依循一致的命名慣例。不過運氣更差的時候，一套系統中可能會充斥着多套命名慣例。這有多是由於開發團隊由多組人馬所構成，每組人馬都有不一樣的文化，而在專案開發管理又沒有管控得宜所形成。最糟的狀況，程式碼徹底沒有明顯的慣例可言，這時候閱讀的難度就更高了。

想要閱讀程式碼，得先試着體會程式碼做者的「心」。想要這麼作，就得多瞭解對方所使用的語言，以及慣常運用的語彙。在下一回中，咱們將繼續探討閱讀程式碼的相關議題。

設計模式

閱讀他人的程式碼（ 2 ） -摸清架構，即可輕鬆掌握全貌服務器

在本文中，咱們的重點放在：要了解一個系統，最好是採起由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，由於那一般對於你瞭解全貌，沒有多大的幫助。閱讀程式碼不須要從第一行讀起，咱們的目的並非在於讀遍每一段程式碼。架構

基於許多緣由，程式人須要閱讀其餘人所寫成的程式碼。而對程式設計2.0時代的程式人來講，最正面的價值在於，能讀懂別人程式的人，纔有能力從中萃取本身所需的程式，藉以提升生產力。

閱讀程式碼的目的，在於瞭解全貌而非細節
想要讀懂別人程式碼的根本基礎，即是瞭解對方所用的程式語言及命名慣例。有了這個基礎以後，纔算是具有了基本的閱讀能力。正如我以前提到的─ ─想要讀懂法文寫成的小說，總不能連法文都不懂吧。閱讀程式碼和閱讀文學做品，都須要瞭解撰寫所用的語言及做者習用的語彙。

但咱們在閱讀文學做品一般是採循序的方式，也就是從第一頁開始，一行一行地讀下去，依循做者爲你鋪陳的步調，逐漸進到他爲你準備好的世界裏。閱讀程式碼卻大大不一樣。咱們不多從第一行開始讀起，由於除非它是很簡單的單執行緒程式，不然不多這麼作。由於要是這麼作，就很難了解整個系統的全貌。是的，咱們這邊提到了一個重點，閱讀程式碼的目的在於瞭解系統的全貌，而不是在於只是爲了地毯式的讀遍每一段程式碼。

就拿物件導向程式語言所寫成的系統來講，整個系統被拆解，分析成爲一個個獨立的類別。閱讀個別類別的程式碼，或許能夠明白每項類別物件個別的行爲。但對於各種別物件之間如何交互影響，如何協同工做，又很容易陷入盲人摸象的困境。這是由於各種別的程式碼，只描述個別物件的行爲，而片斷的閱讀就只能造就片面的認識。

由上而下釐清架構後，即可輕易理解組成關係
若是你想要跳脫困境，不想浪費大量時間閱讀程式碼，卻始終只能捕捉到對系統片斷認識，就必須轉換到另外一種觀點來看待系統。從個別的類別行爲着手，是由下至上（自下而上）的方法;在閱讀程式碼時，卻應該先採由上至下（自上而下）的方式。對程式碼的閱讀來講，由上至下意謂着，你得先了解整個系統架構。

系統的架構是整個系統的骨幹，支柱。它表現出系統最突出的特徵。知道系統架構究竟屬於那一種類型，一般大大有益於瞭解系統的個別組成之間的靜態及動態關係。有些系統由於所用的技術或框架的關係，決定了最上層的架構。例如，採用的Java Servlet的/ JSP的技術的應用系統，最外層的架構即是以J2EE的（或起碼的J2EE中的Web容器）爲根本。

使用的Java Servlet的/ JSP的技術時，決定了某些組成之間的關係。例如， Web容器依據web.xml中的內容載入全部的Servlets ，聽衆，以及過濾器。每當語境發生事件（例如初始化）時，它便會通知監聽類別。每當它收到來自客戶端的請求時，便會依循設定的全部過濾器鏈，讓每一個過濾器都有機會檢查並處理此一請求，最後再將請求導至用來處理該請求的Servlet的。

當咱們明白某個系統採用這樣的架構時，即可以很容易地知道各個組成之間的關係。即便咱們還不知道究竟有多少Servlets ，但咱們會知道，每當收到一個請求時，老是會有個相對應的服務器來處理它。當想要關注某個請求如何處理時，我應該去找出這個請求對應的服務器。

瞭解架構，必需要加上層次感
一樣的，以爪哇寫成的網頁應用程式中，也許會應用諸如Struts的之類的的MVC框架，以及像Hibernate的這樣的資料存取框架。它們均可以視爲最主要的架構下的較次級架構。而各個應用系統，甚至有可能在Struts的及休眠之下，創建自有的更次級的架構。

也就是說，當咱們談到「架構」這樣的觀念時，必需要有層次感。而不管是那一層級的架構，都會定義出各自的角色，以及角色間的關係。對閱讀者來講，相較於直接切入最細微的單一角色行爲，不如瞭解某個特定的架構中，究竟存在多少角色，以及這些角色之間的互動模式，比較可以幫助咱們瞭解整個系統的運做方式。

這是一個很重要的關鍵，當你試着進到最細節處以前，應該先試着找出參與的角色，及他們之間的關係。例如，對事件驅動式的架構而言，有3個很重要的角色。一個是事件處理的分派器（事件調度），一個是事件產生者（事件發生器），另外一個則是事件處理器（事件處理程序）。

事件產生器產生事件，並送至事件分派器，而事件分派器負責找出各事件相對應的事件處理器，而且轉交該事件，並命令事件處理器加以處理。像的圖形用戶界面的Windows應用程式，即是採用事件驅動式的架構。

當你知道此類的應用程式皆爲事件驅動式的架構時，你即可以進一步得知，在這樣的架構下會有3種主要的角色。雖然也許還不清楚整個系統中，究竟會須要處理多少事件的類型，但對你而言，已經創建了對系統全貌最概觀的認識。

雖然你還不清楚全部的細節，但諸如確切會有那些事件類型之類的資訊，在此刻還不重要─ ─不要忘了，咱們採起的是由上而下的方式，要先摸清楚主建築結構，至於壁紙的花色怎麼處理，那是到了尾聲時纔會作的事。

探索架構的第一件事：找出系統如何初始化
有經驗的程式人，對於時常被運用的架構都很熟悉。經常只須要瞧上幾眼，就能明白一個系統所用的架構，天然就可以直接聯想到其中會存在的角色，以及角色間的關係。然而，並非每一個系統所用的架構，都是大衆所熟悉，或是一眼可以望穿的。這時候，你須要探索。目標一樣要放在界定其中的角色，以及角色間的靜態，動態關係。

不論某個系統所採用的架構是否爲大部分人所熟知的，在試着探索一個系統的長相時，咱們應該找出來幾個答案，瞭解在它所用的架構下，下列這件事是如何被完成的：一，系統如何初始化，二，與這個系統相接的其餘系統（或使用者）有那些，而相接的介面又是什麼;三，系統如何反應各類事件，四，系統如何處理各類異常及錯誤。

系統如何初始化是很重要的一件事，由於初始化是爲了接下來的全部事物而作的準備。從初始化的方式，內容，能知道系統作了什麼準備，對於系統會有什麼行爲展示，也就能得窺一二了。之因此要了解與系統相接的其餘系統（或使用者），爲的是要界定出系統的邊界。其餘的系統可能會提供輸入給咱們所探索的系統，也可能接收來自這系統的輸出，瞭解這邊界所在，才能肯定系統的外觀。

而系統所反應的事件類型，以及如何反應，基本上就表明着系統自己的主要行爲模式。最後，咱們必須瞭解系統處理異常及錯誤的方式，這一樣也是系統的重要行爲，但容易被忽略。以前，咱們提到必須先具有一個系統的語言基礎，纔可以進一步加以閱讀，而在本文中，咱們的重點放在：要了解一個系統，最好是採起由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，由於那一般對於你瞭解全貌，沒有多大的幫助。框架

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

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

閱讀程式碼的動做，能夠是很原始的，利用最簡單的文字編輯器，逐一開啓原始碼，而後憑藉着一己的組織能力，在不一樣的程式碼間跳躍，拼湊出腦中想要構建的圖像。
不過，系統的複雜度每每超過人腦的負荷。閱讀程式碼的時候，你會須要更多工具提供協助。使用好的整合式開發環境（ IDE ）的或文字編輯器，就能提供最基本的幫助。

善用文字編輯器或IDE中，加速解讀程式碼
許多文字編輯器提供了常見程式語言的語法及關鍵字標示功能。這對於閱讀來講，絕對可以起很大的做用。有些文字編輯器（例如我經常使用的編輯器及偶而使用的記事本+ + ），甚至可以自動列出某個原始檔中全部定義的函式清單，更容許你直接從清單中選擇函式，直接跳躍到該函式的定義位置。這對於閱讀程式碼的人來講，就提供了極佳的便利性。

由於在閱讀程式碼時，最常作的事，就是隨着程式中的某個控制流，將閱讀的重心，從某個函式移至它所呼叫的另外一個函式。因此對程式人來講，閱讀程式碼時最常作的事之一就是：找出某個函式位在那一個原始檔裏，接着找到該函式所在的位置。

好的的IDE可以提供的協助就更多了。有些可以自動呈現一些額外的資訊，最有用的莫過於函式的原型宣告了。例如，有些的IDE支援當遊標停留在某函式名稱上一段時間後，它會以提示的方式顯示該函式的原型宣告。

對閱讀程式碼的人來講，在看到程式碼中呼叫到某個函式時，能夠直接利用這樣的支援，當即取得和這個函式有關的原型資訊，立刻就能知道呼叫該函式所傳入的各個引數的意義，而沒必要等到將該函式的定義位置找出後，才能明白這件事。

grep按（讀者：推薦來源透視）是一個基本而極爲有用的工具
除了選用好的文字編輯器或的IDE以外，還有一個基本，但卻極爲有用的工具，它就是grep按。熟悉的Unix做業系統的程式人，對grep按這個公用程式多半都不陌生。 grep按最大的用途，在於它容許咱們搜尋某個目錄（包括遞迴進入全部子目錄）中全部指定檔案，是否有符合指定條件（常數字串或正規表示式）檔案。

假若有的話，則能幫你指出所在的位置。這在閱讀程式碼時的做用極大。當咱們隨着閱讀的腳步，趕上了任何一個不認識，但自認爲重要的類別，函式，資料結構定義或變數，咱們就得找出它究竟位在這茫茫程式碼海中的何處，才能將這個圖塊從未知變爲已知。
grep按之因此好用，就是在於當咱們發現某個未知的事物時，能夠輕易地利用它找出這個未知的事物究竟位在何方。此外，雖然說grep按是Unix系統的標準公用程式之一，可是像視窗這樣子的平臺，也有各類類型的grep按程式。對於在視窗環境工做的程式人來講，能夠自行選用以爲稱手的工具。

gtags可創建索引，讓搜尋更有效率
grep按雖然好用，可是仍然有一些不足之處。第一個缺點在於它並不會爲所搜尋的原始碼檔案索引。每當你搜尋時，它都會逐一地找出全部的檔案，而且讀取其中的全部內容，過濾出知足指定條件的檔案。當專案的原始碼數量太大時，就會產生搜尋效率不高的問題。

第二個缺點是它只是一個單純的文字檔搜尋工具，自己並不會剖析原始碼所對應的語言語法。當咱們只想針對「函式」名稱進行搜尋時，它有可能將註解中含有該名稱的原始碼，也一併找了出來。

針對grep按的缺點，打算閱讀他人程式碼的程式人，能夠考慮使用像是gtags這樣子的工具。 gtags是源代碼的GNU全局標記系統，它不僅搜尋文字層次，並且由於具有了各類語言的語法剖析器，因此在搜尋時，能夠只針對和語言有關的元素，例如類別名稱，函式名稱等。

並且，它能針對原始碼的內容進行索引，這意謂一旦建好索引以後，每次搜尋的動做，都毋需從新讀取全部原始碼的內容並逐一搜尋。只須要以現成的索引結構爲基礎，便可有效率的尋找關鍵段落。

gtags提供了基於命令列的程式，讓你指定原始碼所在的目錄執行創建索引的動做。它同時也提供程式讓你得如同操做grep按通常，針對索引結構進行搜尋及檢索。它提供了許多有用的檢索方式，例如找出專案中定義某個資料結構的檔案及定義所在的行號，或者是找出專案中全部引用某資料結構的檔案，以及引用處的行號。

這麼一來，你就能夠輕易地針對閱讀程式碼時的需求予以檢索。相較於grep按所能提供的支援， gtags這樣的工具，簡直是強大許多。

再搭配htags製做的HTML文件，更是如虎添翼
還有一個絕對須要一提的工具。這個叫作htags的工具，可以幫你將已製做完成的索引結構，製做成爲一組相互參考的的HTML文件。基本上，利用這樣的的HTML文件閱讀程式碼，比起單純地直接閱讀原始碼，來得更有結構。緣由是閱讀程式碼時，這樣的的HTML文件，已經爲你創建起在各個原始碼檔案片斷間跳躍的鏈結。例如，圖一是針對一個有名的開放原始碼專案ffmpeg ，由gtags所產生出來的的HTML文件首頁的一部分。

htags工具首先爲你找出全部定義的Main （）函式的檔案，而且列出所在的函式。找出的Main （）函式，時常是閱讀程式碼的第一步，由於主要（）函式是程式的主要入口點，全部的動做皆由此啓動，它是一切事物的源頭。
憑藉htags製做的的HTML文件，你能夠輕易地點擊超連結，直接進到的Main （）函式所在的程式碼片斷，如圖二。

當咱們檢視上述原始碼時，發現av_register_all （）是個陌生，沒法瞭解的事物，而想要搞懂它到底是什麼，能夠再繼續點擊這個函式，如圖三。這真是太方便了！閱讀至此，你會猛然發現， gtags彷彿就是爲了閱讀程式碼而專門量身打造的利器。

post

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

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

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

好的說明文件難求，拼湊故事的能力很重要
有些系統提供良善的說明文件，也許還利用UML的充分描述系統的運做情境。那麼對於閱讀者來講，從系統的分析及設計文件着手，即是快速瞭解系統運做情境的一個途徑。
可是，並非每一個軟體專案都伴隨着良好的系統文件，而許多極具價值的開放原始碼專案，也時常不具有此類的文件。對此，閱讀者必須嘗試自行捕捉，並適度地記錄捕捉到的運做情境。

我喜歡將系統的運做情境，比擬成系統會上演的故事情節。在閱讀細節性質的程式碼前，先知道系統究竟會發生那些故事，是必備的基本功課。你能夠利用熟悉或者本身發明的表示工具，描述你所找到的情境。甚至能夠只利用簡單的列表，直接將它們列出。只要可以達到記錄的目的，對程式碼閱讀來講，都可以提供幫助。或者，你也能夠利用基於UML中的類別圖，合做圖，循序圖之類的表示方法，作出更詳細的描述。
當你可以列出系統可能會有的情境，表示你對系統所具有的功能，以及在各類狀況下的反應，都具有歸納性的認識。以此爲基礎，即可在任何須要的時候，鑽進細節處深刻了解。

探索架構的第一步─ ─找到程式的入口
在以前，咱們在一個開發專案中，曾經須要將系統所獲得的的MP3音訊檔，放至iPod的這個極受歡迎的播放設備中。

雖然iPod的自己也能夠作爲可移動式的儲存設備，但並非單純地將MP3播放檔案放到中的iPod ，就可讓蘋果的播放器認得這個檔案，甚至可以加以播放。
這是由於蘋果利用一個特殊的檔案結構（ iTunes的數據庫），記錄播放器中可供播放的樂曲，播放清單以及樂曲資訊（例如專輯名稱，樂曲長度，演唱者等）。爲了瞭解而且試着重複使用既有的程式碼，咱們找到了一個AOL的Winamp的iPod的外掛程式（插件）。

AOL的Winamp是我的電腦上極受歡迎的播放軟體，而咱們找到的外掛程式，能讓的軟件直接顯示鏈接至電腦的的iPod中的歌曲資訊，而且容許的軟件直接播放。

咱們追蹤與閱讀這個外掛程式的思路及步驟以下，首先，咱們要先了解外掛程式的系統架構。很明顯的，大概瀏覽過原始碼後，咱們注意到它依循着AOL的Winamp爲插件程式所制定的規範，也就是說，它是實做成的Windows上的DLL的，而且透過一個叫作winampGetMediaLibraryPlugin的DLL的函式，提供一個名爲winampMediaLibraryPlugin的結構。
當咱們不清楚系統的架構究竟爲什麼時，咱們會試着探索，而第一步，即是找到程式的入口。如何找到呢？這會依程式的性質不一樣而有所差異。
對一個自己就是可獨立執行的程式來講，咱們會找啓動程式的主要函式，例如對的C / C + +來講就是主要（），而對爪哇來講，即是靜無效的main （）。在找到入口後，再逐一追蹤，摸索出系統的架構。
但有時，咱們所欲閱讀的程式碼是類別庫或函式庫，它只是用來提供多個類別或函式供用戶端程式（客戶程序）使用，自己並不具單一入口，此類的程式碼具備多重的入口─ ─每一個容許用戶端程式呼叫的函式或類別，都是它可能的入口。

例如，對AOL的Winamp的iPod的插件來講，它是一個動態連接庫形式的函式庫，因此當咱們想了解它的架構時，必需要先找出它對外提供的函式，而對的Windows的DLL來講，對外提供的函式，皆會以dllexport這個關鍵字來修飾。因此，不管是利用grep按或gtags之類的工具，咱們能夠很快從原始碼中，找到它只有一個DLL的函式（這對咱們而言，真是一個好消息），而這個函式即是上述的winampGetMediaLibraryPlugin 。

系統多會採用相同的架構處理插件程式
若是經驗不夠的話，也許沒法直接猜出這個函式的做用。
不過，若是你是個有經驗的程式人，多半能從函式所回傳的結構，猜出這個函式實際的用途。而事實上，當你已經知道它是一個插件程式時，就應該要明白，它可能採用的，就是許多系統都採用的相同架構處理插件程式。

當一個系統採用所謂插件形式的架構時，它一般不會知道它的插件究竟會怎麼實做，實做什麼功能。它只會規範插件程式須要知足某個特定介面。當系統初始化時，全部的插件均可以依循相同的方式，向系統註冊，合法宣示本身的存在。

雖然系統並不確切知道插件會有什麼行爲展示，可是由於它制定了一個標準的介面，因此係統仍然能夠預期每一個插件可以處理的動做類型。這些動做具體上怎麼執行，對系統來講並不重要。這也正是物件導向程式設計中的「多型」觀念。

隨着實務經驗，概括常見的架構模式
我想表達的重點，是當你「涉世越深」以後，所接觸的架構越多，就越能舉一反三。只須要瞧上幾眼，就能明白系統所用的架構，天然就可以直接聯想到其中可能存在的角色，以及角色間的關係。

像上述的插件程式手法，時常能夠在許多容許「外掛」程式碼的系統中看到。因此，有經驗的閱讀者，多半可以當即反應，知道像這樣的系統的軟件，應該是讓每一個插件程式，都寫成DLL的函式庫。

而每一個插件的DLL的函式庫中，都必須提供winampGetMediaLibraryPlugin （）這個函式（若是你熟悉的Windows的程式設計，你會知道這是利用加載（）和GetProcAddress （）來達成的一種多型手法）。若是你熟悉設計模式，你更會知道這是簡單工廠方法這個設計模式的運用。
winampGetMediaLibraryPlugin （）所回傳的winampMediaLibraryPlugin結構，正好就描述了每一個AOL的Winamp插件的實做內容。

善用名稱可加速瞭解
利用gtags這個工具，咱們當即發現，這個插件它所定義的初始化，退出， PluginMessageProc這三個名稱，都是函式名稱。這暗示在多型的做用下，它們都是在某些時間點，會由AOL的Winamp核心本體呼叫的函式。

名稱及命名慣例是很重要的。看到「初始化」，咱們會知道它的做用多半是進行初始化的動做，而「退出」大概就是結束時處理函式，而PluginMessageProc多半就是各類訊息的處理常式（過程一般是程序的簡寫，因此PluginMessageProc意指插件訊息程序）了。

「望文生義」很重要，咱們看到函式的名稱，就能夠猜測到它所表明的做用，例如：當AOL的Winamp嘗試着初始化一個插件時，它會呼叫這個結構中的初始化函式，以便讓每一個插件程式有機會初始化本身;當AOL的Winamp打算結束本身或結束某個插件的執行時，便會呼叫退出函式。當AOL的Winamp要和插件程式溝通時，它會發送各類不一樣的訊息至插件，而插件程式必須對此作出迴應。

咱們甚至不須要檢視這幾個函式的內容，就能夠作出推測，而這樣的假設，事實上也是正確的。

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

根據須要決定展開的層數，或展開特定節點，並記錄樹狀結構，而後適度忽略不須要了解的細節─這是一個很重要的態度。由於你不會一次就須要全部的細節，閱讀都是有目的的，每次的閱讀也許都在探索程式中不一樣的區域。

探索系統架構的第一步，就是找到程式的入口點。找到入口點後，多半採起由上而下（自上而下）的方式，由最外層的結構，一層一層逐漸探索愈來愈多的細節。
咱們的開發團隊曾針對AOL的Winamp的iPod的插件進行閱讀及探索，不只找到入口點，也找出，並理解它最根本的基礎架構。從這個入口點，能夠往下再展開一層，分別找到三個重要的組成及其意義：
●的init （）：初始化動做
     ●退出（）：終止化動做
     ● PluginMessageProc （）：以訊息的方式處理程式所必須處理的各類事件

展開的同時，隨手記錄樹狀結構
當咱們從一個入口點找到三個分支後，能夠順着每一個分支再展開一層，因此分別繼續閱讀的init ，退出，以及PluginMessageProc的內容，並試着再展開一層。閱讀的同時，你能夠在文件中試着記錄展開的樹狀結構。
●的init （）：初始化動做
     ● itunesdb_init_cc （）：創建存取iTunes的數據庫的同步物件
     ●初始化資料結構
     ●初始化的GUI元素
     ●載入設定
     ●創建日誌檔
     ● autoDetectIpod （）：偵測的iPod插入的執行緒
     ●退出（）：終止化動做
     ● itunesdb_del_cc （）：終止存取iTunes的數據庫的同步物件
     ●關閉日誌檔
     ●終止化圖形用戶界面元素
     ● PluginMessageProc （）：以訊息的方式處理程式所必須面臨的各類事件
     ●執行所鏈接之蘋果的MessageProc （）

這部分必需要留意幾個重點。首先，應該一邊閱讀，一邊記錄文件。由於人的記憶力一般有限，對於陌生的事物更是容易遺忘，所以邊閱讀邊記錄，是很好的輔助。
再者，由於咱們採起由上而下的方式，從一個點再分支出去成爲多個點，所以，一般也會以樹狀的方式記錄。除此以外，每次只試着往下探索一層。從的init （）來看你便會明白。

如下試着摘要的init （）的內容：
詮釋的init （）（
itunesdb_init_cc （） ;
currentiPod =空;
蘋果=新C_ItemList ;
...略
conf_file = （字符* ） SendMessage
（ plugin.hwndWinampParent ， WM_WA_IPC ， 0 ， IPC_GETINIFILE ） ;
m_treeview = GetDlgItem （ plugin.hwnd LibraryParent ， 0x3fd ） ;
/ /這個數字其實是魔術：）
...略
g_detectAll = GetPrivateProfileInt （「 ml_ipod 」，「 detectAll 」， 0 ， conf_file ）！ = 0 ;
...略
g_log = GetPrivateProfileInt （「 ml_ipod 」，「日誌」， 0 ， conf_file ）！ = 0 ;
...略
g_logfile =打開（ g_logfilepath ，有「 A 」） ;
...略
autoDetectIpod （） ;
返回0 ;
）

由於咱們只試着多探索一層，而目的是但願發掘出下一層的子動做。因此在的init （）中看到像「 itunesdb_init_cc （） ; 」這樣的函式呼叫動做時，咱們知道它是在初始化（）之下的一個獨立子動做，因此能夠直接將它列入。可是當看到以下的程式行：
currentiPod =空;
蘋果=新C_ItemList ;

咱們並不會將它視爲的init （）下的一個獨立的子動做。由於好幾行程式，才構成一個具備獨立抽象意義的子動做。例如以上這兩行構成了一個獨立的抽象意義，也就是初始化所需的資料結構。

理論上，原來的程式撰寫者，有可能撰寫一個叫作init_data_structure （）的函式，包含這兩行程式碼。這樣作可讀性更高，然而基於種種理由，原做者並無這麼作。身爲閱讀者，必須自行解讀，將這幾行合併成單一個子動做，並賦予它一個獨立的意義─ ─初始化資料結構。

沒法望文生義的函式，先試着預看一層
對於某些不明做用的函式叫用，不是望其文便能生其義的。當咱們看到「 itunesdb_init_cc （）」這個名稱時，咱們或許能從「 itunesdb_init 」的字眼意識到這個函式和蘋果所採用的的iTunes數據庫的初始化有關，但「循環」卻實在使人費解。爲了理解這一層某個子動做的真實意義，有時免不了要往前多看一層。

原來它是用來初始化同步化機制用的物件。做用在於這程式必定是用了某個內部的資料結構來儲存的iTunes數據庫，而這資料結構有可能被多執行緒存取，因此必須以同步物件（此處是視窗的臨界區）加以保護。

因此說，當咱們試着以樹狀的方式，逐一展開每一個動做的子動做時，有時必須多看一層，才能真正瞭解子動做的意義。由於有了這樣的動做，咱們能夠在展開樹狀結構中，爲itunesdb_init_cc （）附上補充說明：創建存取iTunes的數據庫的同步物件。這麼一來，當咱們在檢視本身所寫下的樹狀結構時，就能輕易一目瞭然的理解每一個子動做的真正做用。

根據須要瞭解的粒度，決定展開的層數
咱們究竟須要展開多少層呢？這個問題和閱讀程式碼時所需的「粒度（粒度）」有關。若是咱們只是須要歸納性的瞭解，那麼也許展開兩層或三層，就可以對程式有基礎的認識。假若須要更深刻的瞭解，就會須要展開更多的層次才行。

有時候，你並非一視同仁地針對每一個動做，都展開到相同深度的層次。也許，你會基於特殊的需求，專門針對特定的動做展開至深層。例如，咱們閱讀AOL的Winamp的iPod插件的程式目錄，實際上是想從中瞭解究竟應該如何存取的iPod上的iTunes的數據庫，使咱們可以將MP3播放歌曲或播放清單加至此數據庫中，並於的iPod中播放。

當咱們層層探索與分解以後，找到了parseIpodDb （），從函式名稱判斷它是咱們想要的。由於它表明的正是剖析iPod的數據庫，正是咱們這次閱讀的重點，也就達成閱讀這程式碼的目的。

咱們強調一種不一樣的作法：在閱讀程式碼時，多半採起由上而下的方式，而本文建議了一種記錄閱讀的方式，就是試着記錄探索追蹤時層層展開的樹狀結構。你能夠視本身須要，瞭解的深刻程度，再決定要展開的層數。你更能夠依據特殊的須要，只展開某個特定的節點，以探索特定的細目。

適度地忽略不須要了解的細節，是一個很重要的態度，由於你不會一次就須要全部的細節，閱讀都是有目的的。每次的閱讀也許都在探索程式中不一樣的區域;而每次探索時，你均可以增補樹狀結構中的某個子結構。漸漸地，你就會對這個程式更加的瞭解。

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

即使每一個人的寫做模式多半受到他人的影響，程式人一般仍是會融合多種風格，而成爲本身獨有的特點，若是你知道做者程式設計的偏好，閱讀他的程式碼就更駕輕就熟。

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

創建架構觀點的認識是最重要的事情。雖然這一系列的文章前提爲「閱讀他人的程式碼」，但咱們真正想作的工做，並不在於完全地詳讀每一行程式碼的細節，而是想要透太重點式的程式碼「摘讀」，達到對系統所需程度的瞭解。每一個人在閱讀程式碼的動機不盡相同，須要瞭解的程度也就有深淺的分別。只有極爲少數的狀況下，你纔會須要細讀每一行程式碼。

閱讀程式碼是新時代程式人必備的重要技能
這一系列的文章至此已近尾聲，回顧曾探討的主題，咱們首先研究了閱讀程式碼的動機。尤爲在開放原始碼的風氣如此之盛的狀況下，妥善利用開放原始碼所提供的資源，不只可以更快學習到新的技術，同時在原始碼版權合適時，還能夠直接利用現成的程式碼，大幅地提升開發階段的生產力。因此，閱讀程式碼儼然成爲了新時代程式人必備的重要技能之一。
接着，咱們提到了閱讀程式碼前的必要準備，包括了對程式語言，命名慣例的瞭解等等。在此以後，咱們反覆提起了「由上而下」的閱讀方向的重要性。
由上而下的閱讀方式，是由於咱們重視架構更勝於細節。從最外層的架構逐一貫內探索，每往內探索一層，咱們瞭解系統的粒度就增長了一個等級。當你識別出系統所用的架構時，便可以輕易瞭解在這個架構下會有的角色，以及它們之間的動態及靜態的關係。如此一來，許多資訊便不言可喻，毋需額外花費力氣，便可以快速理解。

好的名稱可以摘要性地點出實體的做用
追蹤原始碼時，當然能夠用原本的方式，利用編輯器開啓所需的檔案，而後利用編輯器提供的機制閱讀，可是假若可以善用工具，閱讀程式碼的效率及品質都能大大提高。在本系列文章中，咱們介紹了一些工具，或許你還能夠在坊間找到其餘更有用的工具。
我在這一系列的文章中，實際帶着你們閱讀，追蹤了一個名爲ml_pod的開放原始碼專案。它是一個AOL的Winamp的iPod的外掛程式。在追蹤的過程當中，咱們試着印證這一系列文中所提到的觀念及方法。咱們採用逐漸開展的樹狀結構來記錄追蹤的過程，並藉以創建起對系統的概觀認識。

就原始碼的閱讀來講，以前的討論涉及了工具面及技巧面。但還有一些主題不在這兩個範疇以內，例如，善用名稱賦予你的提示。名稱作爲隱喻（隱喻）的做用很大，好的名稱可以摘要性地點出實體的做用，例如咱們看到autoDetectIpod （），天然而然可以想像它的做用在於自動（自動）偵測（檢測）的iPod的存在。

咱們在展開樹狀結構時，有時候須要預看一層，有時卻不須要這麼作，即可獲得印證。程式人都會有慣用的名稱以及組合名稱的方法，假若可以從名稱上理解，便毋需鑽進細節，能夠省去至關多的時間。例如，當咱們看到parseIpodDb （）時，即可以輕易瞭解它是剖析（解析）的iPod的資料庫（ DB ）的，所以便不須要當即鑽進parseIpodDb （）中查看底細。

儘管如此，可否理解程式人命名的用意，和自身的經驗以及是否瞭解原做者的文化背景，是息息相關的。

命名自己就是一種文化產物。不一樣的程式人文化，就會衍生出不一樣的命名文化。當你本身的經驗豐富，看過及接觸過的程式碼也多時，對於名稱的感覺及聯想的能力天然會有不一樣。

這種感覺和聯想的能力，究竟應該如何精進，很難具體描述。就我我的的經驗，多觀察不一樣命名體系的差別，而且嘗試概括彼此之間的異同，有助於更快地提高對名稱的感覺及聯想力。

轉換立場，理解做者的思考方式
除了工具及技巧以外，「想要閱讀程式碼，得先試着閱讀寫這個程式碼的程式人的心。」這句話說來十分抽象，或許也使人難以理解。

當你在閱讀一段程式碼時，或許能夠試着轉換本身的立場，從旁觀者的角度轉換成爲寫做者的心態，揣摩原做者的心理及處境。當你試着設身處地站在他的立場，透過他的思考方式來閱讀，追蹤他所寫下的程式碼，將會感受更加流暢。

許多軟體專案，都不是由單一程式人所獨力完成。所以，在這樣的專案中，便有可能呈現多種不一樣的風格。

許多專案會由架構師決定主體的架構及運做，有既定實施的命名慣例，及程式設計須要遵照方針。在多人開發的模式下，越是好的軟體專案，越看不出某程式碼片斷到底是由誰所寫下的。

不過，有些開放原始碼的專案，每每又整合了其餘開放原始碼的專案。有的時候，也很難求風格的統一，便會出現混雜的狀況。比如以前提到的ml_pod專案，由於程式碼中混合了不一樣的來源，而呈現風格不一致的狀況。

我在閱讀非本身所寫的程式碼時，會觀察原做者寫做的習慣，藉以對應到腦中所記憶的多種寫做模型。在閱讀的過程當中，讀完幾行程式碼，我會試着猜測原做者在寫下這段程式碼時的心境。他寫下這段程式碼的用意是什麼？爲何他會採起這樣的寫法？順着原做者的思考理路閱讀，本身的思考才能更貼近對方寫做當時的想法。

當你短暫化身爲原做者時，才能更輕易的理解他所寫下的程式碼。
若是你能知道原做者的背景，程式設計時的偏好，閱讀他的程式碼，就更能駕輕就熟了。

從程式碼着手認識做者獨有的風格，進而見賢思齊
我在閱讀別人寫下的程式碼時，我會試着猜測，原做者到底是屬於那一種「流派」呢？每一個人都有本身獨特的寫做模式，即使每一個人的寫做模式多半受到他人的影響─ ─不管是書籍的做者，學習過程當中的指導者，或一同參與專案的同儕，但每一個程式人一般會融合多種風格，而成爲本身獨有的風格。

物件導向的基本教義派，老是會以他心中以爲最優雅的物件導向方式來撰寫程式。而閱讀慣用，善用設計模式的程式人所寫下的程式碼時，不難推想出他會在各類常見的應用情境下，套用哪些模式。

有些時候，在閱讀之初，你並不知道原做者的習性跟喜愛，甚至你也不知道他的功力。可是，在閱讀以後，你會慢慢地從一個程式人所寫下的程式碼，開始認識他。

你或許會在閱讀他人的程式碼時，發現使人拍案叫絕的技巧或設計。你也有可能在閱讀的同時，發現原做者所留下的缺失或寫做時的缺點，而暗自警戒於心。這也算是閱讀他人程式碼時的一項樂趣。

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