(轉)如何閱讀他人的程序代碼（上）

一、讀懂程序代碼，使心法皆爲我所用
 
程序代碼是別人寫的，只有原作者才真的瞭解程序代碼的用途及涵義。許多程序人心裏都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程序代碼。但是，與其抗拒接收別人的程序代碼，不如徹底瞭解相關的語言和慣例，當成是培養自我實力的基石。
 
  
 
對大多數的程序人來說，撰寫程序代碼或許是令人開心的一件事情，但我相信，有更多人視閱讀他人所寫成的程序代碼爲畏途。許多人寧可自己重新寫過一遍程序代碼，也不願意接收別人的程序代碼，進而修正錯誤、維護它們、甚至加強功能。 
 
這其中的關鍵究竟在何處呢？若是一語道破，其實也很簡單，程序代碼是別人寫的，只有原作者才真的瞭解程序代碼的用途及涵義。許多程序人心裏都有一種不自覺的恐懼感，深怕被迫去碰觸其他人所寫的程序代碼。這是來自於人類內心深處對於陌生事物的原始恐懼。 
 
  
 
讀懂別人寫的程序代碼，讓你收穫滿滿 
 
不 過，基於許多現實的原因，程序人時常受迫要去接收別人的程序代碼。例如，同事離職了，必須接手他遺留下來的工作；也有可能你是剛進部門的菜鳥，而同事經驗 值夠了、升級了，風水輪流轉，一代菜鳥換菜鳥。甚至，你的公司所承接的項目，必須接手或是整合客戶前一個廠商所遺留下來的系統，你們手上只有那套系統的原 始碼（運氣好時，還有數量不等的文件）。 
 
諸如此類的故事，其實時常在程序人身邊或身上持續上演着。許多程序人都將接手他人的程序代碼，當做一件悲慘的事情。每個人都不想接手別人所撰寫的程序代碼，因爲不想花時間去探索，寧可將生產力花在產生新的程序代碼，而不是耗費在瞭解這些程序代碼上。 
 
很 遺憾的是，上述的情況對程序人來說很難避免。我們總是必須碰觸到其他人所寫成的程序代碼，甚至必須瞭解它、加以修改。對於這項需求，在現今開放原始碼的風 氣如此盛行的今日，正如之前的「程序設計2.0」文中所提到的，你可以透過開放原始碼學習到新的技術、學習到高手的架構設計，大幅提高學習的效率及效果。 你甚至可以直接自開放原始碼項目中抽取、提煉出自己所需的程序代碼，站在巨人的肩膀上，直接由彼端獲得所需的生產力。從這個觀點來看，讀懂別人所寫的程序 代碼，就不再只是從負面觀點的「被迫接收」，而是極具正面價值的「汲取養份」。 
 
  
 
先了解系統架構與行爲模式，再細讀
 
倘若撰寫程序代碼是程序人的重要技藝之一，那麼讀懂別人的程序代碼、接着加以修改，也勢必是另一個重要的技藝。 
 
如果你不能熟悉這項工作，不僅在遭逢你所不願面對的局面時，無法解決眼前接手他人程序代碼的難題，更重要的是，當你看着眼前現成的程序代碼，卻不知如何從中擷取自己所需，導致最後只能入寶山空手回，望之興嘆。 
 
接觸他人的程序代碼，大致上可以分爲三種程度：一、瞭解，二、修改、擴充，三、抽取、提煉。 
 
瞭解別人的程序代碼是最基礎的工作，倘若不能瞭解自己要處理的程序代碼，就甭論修改或擴充，更不可能去蕪存菁，從中萃取出自己所需，回收再利用別人所撰寫的程序代碼。 
 
雖說是「閱讀」，但程序代碼並不像文章或小說一樣，透過這種做法，便能夠獲得一定程度的瞭解。閱讀文章或小說時，幾乎都是循序地閱讀，你只消翻開第一頁，一行行閱讀下去即可。但是，有許多程序人在試着閱讀其他人的程序代碼時，卻往往有不知如何讀起的困難。 
 
或許找到系統的第一頁（也就是程序代碼執行的啓始點）並不難，但是複雜度高的系統，有時十分龐大，有時千頭萬緒。 
 
從 程序代碼的啓始點開始讀起，一來要循序讀完所有的程序代碼曠日費時，二來透過這種方式來了解系統，很難在腦中構建出系統的面貌，進而瞭解到系統真正的行 爲。所以，閱讀程序代碼的重點，不在於讀完每一行程序代碼，而是在於有效率地透過探索及閱讀，從而瞭解系統的架構及行爲模式。以便在你需要了解任何片段的 細節實作時，能夠很快在腦上對映到具體的程序代碼位置，直到那一刻，纔是細讀的時機。 
 
  
 
熟悉溝通語言與慣例用語 
 
不論如何，有些基本的準備，是閱讀他人程序代碼時必須要有的。 
 
首先，你最好得了解程序代碼寫成的程序語言。想要讀懂法文寫成的小說，總不能連法文都不懂吧。有些情況則很特殊。我們雖然不懂該程序代碼撰寫所用的語言，但是因爲現代語言的高階化，而且流行的程序語言多半都是血統相近，所以即使不那麼熟悉，有時也可勉力爲之。 
 
除了認識所用語言之外，再來就是要先確認程序代碼所用的命名慣例（naming convention）。瞭解命名慣例很重要，不同的程序人或開發團隊，差異可能很大。 
 
這命名慣例涵蓋的範圍通常包括了變量的名稱、函式的名稱、類別（如果是面向對象的話）的名稱、原始碼檔案、甚至是項目建構目錄的名稱。倘若使用了像設計模式之類的方法，這些名稱更有一些具體的表述方式。 
 
命 名慣例有點像是程序人在程序語言之上，另行建構的一組溝通行話。程序人會透過共通約束、遵守的命名慣例，來表達一些較高階的概念。例如，有名的匈牙利式命 名法，便將變量名稱以屬性、型別、說明合併在一起描述。對程序人來說，這種方式能夠提供更豐富的信息，以瞭解該變量的作用及性質。 
 
對 程序代碼閱讀來說，熟悉這個做法之所以重要，是因爲當你瞭解整個系統所採用的慣例時，你便能試着以他們所共同操用的語彙來進行理解。倘若，不能瞭解其所用 的慣例，那麼這些額外提供的信息，就無法爲你所用。像以設計模式寫成的程序代碼，同樣處處充滿着模式的名稱，諸如：Factory、Facade、 Proxy等等。以這些名稱指涉的類別，也直接透過名稱，表達了它們自身的作用。對於懂得這命名慣例的讀者來說，不需要深入探索，也能很快捕捉到這些類別 的意義。 
 
當你拿到一套必須閱讀的程序代碼時，最好先取得命名慣例的說明文件。然而，並不是每套程序代碼都附有此類的說明文件。另一個方式，就是自己到程序代碼中，大略瀏覽一遍，有經驗的程序人可以輕易發掘出該系統所用的命名慣例。 
 
常見的命名方式不脫那幾類，這時候經驗就很重要，倘若你知道的慣例越多，就越能輕易識別他人所用的慣例。如果運氣很糟，程序代碼所用的慣例是前所未見的，那麼你也得花點時間歸納，憑自己的力量找出這程序代碼命名上的規則。 
 
  
 
掌握程序代碼撰寫者的心態與習慣 
 
大 多數的程序代碼，基本上都依循一致的命名慣例。不過運氣更差的時候，一套系統中可能會充斥着多套命名慣例。這有可能是因爲開發團隊由多組人馬所構成，每組 人馬都有不同的文化，而在項目開發管理又沒有管控得宜所造成。最糟的情況，程序代碼完全沒有明顯的慣例可言，這時候閱讀的難度就更高了。 
 
想要閱讀程序代碼，得先試着體會程序代碼作者的「心」。想要這麼做，就得多瞭解對方所使用的語言，以及慣常運用的語彙。在下一回中，我們將繼續探討閱讀程序代碼的相關議題。
 
  
 
  
 
 
  
 
   二、摸清架構，便可輕鬆掌握全貌
 
在本文中，我們的重點放在：要了解一個系統，最好是採取由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，因爲那通常對於你瞭解全貌，沒有多大的幫助。閱讀程序代碼不需要從第一行讀起，我們的目的並不是在於讀遍每一段程序代碼。
 
  
 
基於許多原因，程序人需要閱讀其他人所寫成的程序代碼。而對程序設計2.0時代的程序人來說，最正面的價值在於，能讀懂別人程序的人，纔有能力從中萃取自己所需的程序，藉以提高生產力。 
 
  
 
閱讀程序代碼的目的，在於瞭解全貌而非細節 
 
想要讀懂別人程序代碼的根本基礎，便是瞭解對方所用的程序語言及命名慣例。有了這個基礎之後，纔算是具備了基本的閱讀能力。正如我之前提到的──想要讀懂法文寫成的小說，總不能連法文都不懂吧。閱讀程序代碼和閱讀文學作品，都需要了解撰寫所用的語言及作者習用的語彙。 
 
但我們在閱讀文學作品通常是採循序的方式，也就是從第一頁開始，一行一行地讀下去，依循作者爲你鋪陳的步調，逐漸進到他爲你準備好的世界裏。 
 
閱讀程序代碼卻大大不同。我們很少從第一行開始讀起，因爲除非它是很簡單的單線程程序，否則很少這麼做。因爲要是這麼做，就很難了解整個系統的全貌。 
 
是的，我們這邊提到了一個重點，閱讀程序代碼的目的在於瞭解系統的全貌，而不是在於只是爲了地毯式的讀遍每一段程序代碼。 
 
就 拿面向對象程序語言所寫成的系統來說，整個系統被拆解、分析成爲一個個獨立的類別。閱讀個別類別的程序代碼，或許可以明白每項類別對象個別的行爲。但對於 各類別對象之間如何交互影響、如何協同工作，又很容易陷入盲人摸象的困境。這是因爲各類別的程序代碼，只描述個別對象的行爲，而片段的閱讀就只能造就片面 的認識。 
 
  
 
由上而下釐清架構後，便可輕易理解組成關係 
 
如果你想要跳脫困境，不 想浪費大量時間閱讀程序代碼，卻始終只能捕捉到對系統片段認識，就必須轉換到另一種觀點來看待系統。從個別的類別行爲着手，是由下至上（Bottom- Up）的方法；在閱讀程序代碼時，卻應該先採由上至下（Top-Down）的方式。對程序代碼的閱讀來說，由上至下意謂着，你得先了解整個系統架構。 
 
系統的架構是整個系統的骨幹、支柱。它表現出系統最突出的特徵。知道系統架構究竟屬於那一種類型，通常大大有益於瞭解系統的個別組成之間的靜態及動態關係。 
 
有些系統因爲所用的技術或框架的關係，決定了最上層的架構。例如，採用Java Servlet/JSP技術的應用系統，最外層的架構便是以J2EE（或起碼J2EE中的Web Container）爲根本。 
 
使 用Java Servlet/JSP技術時，決定了某些組成之間的關係。例如，Web Container依據web.xml的內容加載所有的Servlets、Listeners、以及Filters。每當Context發生事件（例如初 始化）時，它便會通知Listener類別。每當它收到來自客戶端的請求時，便會依循設定的所有Filter Chain，讓每個Filter都有機會檢查並處理此一請求，最後再將請求導至用來處理該請求的Servlet。 
 
當我們明白某個 系統採用這樣的架構時，便可以很容易地知道各個組成之間的關係。即使我們還不知道究竟有多少Servlets，但我們會知道，每當收到一個請求時，總是會 有個相對應的Servlet來處理它。當想要關注某個請求如何處理時，我應該去找出這個請求對應的Servlet。 
 
  
 
瞭解架構，必須要加上層次感 
 
同 樣的，以Java寫成的Web應用程序中，也許會應用諸如Struts之類的MVC框架，以及像Hibernate這樣的數據存取框架。它們都可以視爲最 主要的架構下的較次級架構。而各個應用系統，甚至有可能在Struts及Hibernate之下，建立自有的更次級的架構。 
 
也就 是說，當我們談到「架構」這樣的觀念時，必須要有層次感。而不論是那一層級的架構，都會定義出各自的角色，以及角色間的關係。對閱讀者來說，相較於直接切 入最細微的單一角色行爲，不如瞭解某個特定的架構中，究竟存在多少角色，以及這些角色之間的互動模式，比較能夠幫助我們瞭解整個系統的運作方式。 
 
這 是一個很重要的關鍵，當你試着進到最細節處之前，應該先試着找出參與的角色，及他們之間的關係。例如，對事件驅動式的架構而言，有3個很重要的角色。一個 是事件處理的分派器（Event Dispatcher）、一個是事件產生者（Event Generator）、另一個則是事件處理器（Event Handler）。 
 
事件產生器產生事件，並送至事件分派器，而事件分派器負責找出各事件相對應的事件處理器，並且轉交該事件，並命令事件處理器加以處理。像Windows的GUI應用程序，便是採用事件驅動式的架構。 
 
當你知道此類的應用程序皆爲事件驅動式的架構時，你便可以進一步得知，在這樣的架構下會有3種主要的角色。雖然也許還不清楚整個系統中，究竟會需要處理多少事件的類型，但對你而言，已經建立了對系統全貌最概觀的認識。 
 
雖然你還不清楚所有的細節，但諸如確切會有那些事件類型之類的信息，在此刻還不重要──不要忘了，我們採取的是由上而下的方式，要先摸清楚主建築結構，至於壁紙的花色怎麼處理，那是到了尾聲時纔會做的事。 
 
  
 
探索架構的第一件事：找出系統如何初始化 
 
有經驗的程序人，對於時常被運用的架構都很熟悉。常常只需要瞧上幾眼，就能明白一個系統所用的架構，自然就能夠直接聯想到其中會存在的角色，以及角色間的關係。 
 
然而，並不是每個系統所用的架構，都是大衆所熟悉，或是一眼能夠望穿的。這時候，你需要探索。目標同樣要放在界定其中的角色、以及角色間的靜態、動態關係。 
 
不 論某個系統所採用的架構是否爲大部分人所熟知的，在試着探索一個系統的長相時，我們應該找出來幾個答案，瞭解在它所用的架構下，下列這件事是如何被完成 的：一、系統如何初始化，二、與這個系統相接的其他系統（或用戶）有那些，而相接的接口又是什麼；三、系統如何反應各種事件，四、系統如何處理各種異常及 錯誤。 
 
系統如何初始化是很重要的一件事，因爲初始化是爲了接下來的所有事物而做的準備。從初始化的方式、內容，能知道系統做了什麼準備，對於系統會有什麼行爲展現，也就能得窺一二了。 
 
 
之所以要了解與系統相接的其他系統（或用戶），爲的是要界定出系統的邊界。其他的系統可能會提供輸入給我們所探索的系統，也可能接收來自這系統的輸出，瞭解這邊界所在，才能確定系統的外觀。 
 
而系統所反應的事件類型、以及如何反應，基本上就代表着系統本身的主要行爲模式。最後，我們必須瞭解系統處理異常及錯誤的方式，這同樣也是系統的重要行爲，但容易被忽略。 
 
之前，我們提到必須先具備一個系統的語言基礎，才能夠進一步加以閱讀，而在本文中，我們的重點放在：要了解一個系統，最好是採取由上至下的方式。先試着捕捉系統架構性的觀念，不要過早鑽進細節，因爲那通常對於你瞭解全貌，沒有多大的幫助。
 
  
 
  
 
  
 
   三、優質工具在手，讀懂程序非難事
 
系統的複雜度往往超過人腦的負荷。閱讀程序代碼的時候，你會需要更多工具提供協助。使用好的集成開發環境（IDE）或文本編輯器，就能提供最基本的幫助。
 
  
 
閱讀程序代碼的動作，可以是很原始的，利用最簡單的文本編輯器，逐一開啓原始碼，然後憑藉着一己的組織能力，在不同的程序代碼間跳躍，拼湊出腦中想要構建的圖像。 
 
不過，系統的複雜度往往超過人腦的負荷。閱讀程序代碼的時候，你會需要更多工具提供協助。使用好的集成開發環境（IDE）或文本編輯器，就能提供最基本的幫助。 
 
  
 
善用文本編輯器或IDE，加速解讀程序代碼 
 
許 多文本編輯器提供了常見程序語言的語法及關鍵詞標示功能。這對於閱讀來說，絕對能夠起很大的作用。有些文本編輯器（例如我常用的EditPlus及偶而使 用的Notepad++），甚至能夠自動列出某個原始檔中所有定義的函式清單，更允許你直接從清單中選擇函式，直接跳躍到該函式的定義位置。這對於閱讀程 序代碼的人來說，就提供了極佳的便利性。 
 
因爲在閱讀程序代碼時，最常做的事，就是隨着程序中的某個控制流，將閱讀的重心，從某個函式移至它所呼叫的另一個函式。所以對程序人來說，閱讀程序代碼時最常做的事之一就是：找出某個函式位在那一個原始檔裏，接着找到該函式所在的位置。 
 
好的IDE能夠提供的協助就更多了。有些能夠自動呈現一些額外的信息，最有用的莫過於函式的原型宣告了。例如，有些IDE支持當光標停留在某函式名稱上一段時間後，它會以Tooltip的方式顯示該函式的原型宣告。 
 
對閱讀程序代碼的人來說，在看到程序代碼中呼叫到某個函式時，可以直接利用這樣的支持，立即取得和這個函式有關的原型信息，馬上就能知道呼叫該函式所傳入的各個自變量的意義，而不必等到將該函式的定義位置找出後，才能明白這件事。 
 
  
 
grep是一個基本而極爲有用的工具 
 
除 了選用好的文本編輯器或IDE之外，還有一個基本、但卻極爲有用的工具，它就是grep。熟悉Unix操作系統的程序人，對grep這個公用程序多半都不 陌生。Grep最大的用途，在於它允許我們搜尋某個目錄（包括遞歸進入所有子目錄）中所有指定檔案，是否有符合指定條件（常數字符串或正規表示式）檔 案。 
 
倘若有的話，則能幫你指出所在的位置。這在閱讀程序代碼時的作用極大。當我們隨着閱讀的腳步，遇上了任何一個不認識、但自認爲重要的類別、函式、數據結構定義或變量，我們就得找出它究竟位在這茫茫程序代碼海中的何處，才能將這個圖塊從未知變爲已知。 
 
grep 之所以好用，就是在於當我們發現某個未知的事物時，可以輕易地利用它找出這個未知的事物究竟位在何方。此外，雖說grep是Unix的標準公用程序之一， 但是像Windows這樣子的平臺，也有各種類型的grep程序。對於在Windows環境工作的程序人來說，可以自行選用覺得稱手的工具。 
 
  
 
gtags可建立索引，讓搜尋更有效率 
 
grep雖然好用，但是仍然有一些不足之處。第一個缺點在於它並不會爲所搜尋的原始碼檔案索引。每當你搜尋時，它都會逐一地找出所有的檔案，並且讀取其中的所有內容，過濾出滿足指定條件的檔案。當項目的原始碼數量太大時，就會產生搜尋效率不高的問題。 
 
第二個缺點是它只是一個單純的文本文件搜尋工具，本身並不會剖析原始碼所對應的語言語法。當我們只想針對「函式」名稱進行搜尋時，它有可能將批註中含有該名稱的原始碼，也一併找了出來。 
 
針 對grep的缺點，打算閱讀他人程序代碼的程序人，可以考慮使用像是gtags這樣子的工具。gtags是GNU GLOBAL source code tag system，它不只搜尋文字層次，而且因爲具備了各種語言的語法剖析器，所以在搜尋時，可以只針對和語言有關的元素，例如類別名稱、函式名稱等。 
 
而且，它能針對原始碼的內容進行索引，這意謂一旦建好索引之後，每次搜尋的動作，都毋需重新讀取所有原始碼的內容並逐一搜尋。只需要以現成的索引結構爲基礎，即可有效率的尋找關鍵段落。 
 
gtags 提供了基於命令行的程序，讓你指定原始碼所在的目錄執行建立索引的動作。它同時也提供程序讓你得如同操作grep一般，針對索引結構進行搜尋及檢索。它提 供了許多有用的檢索方式，例如找出項目中定義某個數據結構的檔案及定義所在的行號，或者是找出項目中所有引用某數據結構的檔案，以及引用處的行號。 
 
這麼一來，你就可以輕易地針對閱讀程序代碼時的需求予以檢索。相較於grep所能提供的支持，gtags這樣的工具，簡直是強大許多。 
 
  
 
再搭配htags製作HTML文件，更是如虎添翼 
 
 
還 有一個絕對需要一提的工具。這個叫做htags的工具，能夠幫你將已製作完成的索引結構，製作成爲一組相互參考的HTML文件。基本上，利用這樣的 HTML文件閱讀程序代碼，比起單純地直接閱讀原始碼，來得更有結構。原因是閱讀程序代碼時，這樣的HTML文件，已經爲你建立起在各個原始碼檔案片段間 跳躍的鏈結。例如，圖一（略）是針對一個有名的開放原始碼項目ffmpeg，由gtags所產生出來的HTML文件首頁的一部分。 
 
  
 
 
htags工具首先爲你找出所有定義main()函式的檔案，並且列出所在的函式。找出main()函式，時常是閱讀程序代碼的第一步，因爲main()函式是程序的主要入口點，所有的動作皆由此啓動，它是一切事物的源頭。 
 
憑藉htags製作的HTML文件，你可以輕易地點擊超鏈接，直接進到main()函式所在的代碼段，如圖二（略）。 
 
  
 
當我們檢視上述原始碼時，發現av_register_all()是個陌生、無法瞭解的事物，而想要搞懂它究竟是什麼，可以再繼續點擊這個函式，如圖三（略）。這真是太方便了！閱讀至此，你會猛然發現，gtags彷佛就是爲了閱讀程序代碼而專門量身打造的利器。