怎樣高速讀懂別人的項目

做爲入行未深的0基礎程序猿。因爲工做需要接手了別人的項目作優化。才發現已入苦海，因爲可能原做者比較清楚程序的架構以及每行代碼的含義因此很是多地方沒有進行凝視。程序中一些變量以及定義都是使用的縮寫。因此弄懂這些變量的含義就已經讓本身煩躁不安，再加上源代碼體系較大程序中也嵌入了很是多外部的庫往往打開源代碼看上一下子就感受頭都要炸了，簡直是毫無頭緒，多看上幾眼就會認爲十分的煩躁。

只是還好，可能真的是要逼本身一把纔會成長。

固然也沒有辦法，這可是領導分配的任務啊，總不能拿錢不幹活吧。在哪裏都說只是去啊。再說假設能搞定本身也能從中學到很是多東西。那就可勁幹吧。終於仍是完畢了優化任務，而且比計劃要提早了三分之中的一個。

總結來講，做爲0基礎程序猿（我本身就是O(∩_∩)O哈哈~）。切勿急躁！

。！感受越耐不住性子成長的過程就會越緩慢，不會的就上網查資料，或者問同事在論壇上發帖子求助。總能找到解決方式的。

很是感謝咱們的項目負責人，在我工做的這一段時間真是幫助很是大很是大，我本身內心已經將他視爲師傅，從C語言開始手把手教我，儘管現在僅僅是我有問題再去請教他，但他已經教會了我學習的方法，我認爲這纔是最重要的。授之以魚不如授之以漁嘛！

不廢話了，如下是查詢讀別人源碼的時候看到的文章（原文連接已失效）認爲受益不淺就作了摘錄，總的來講就是先理清框架。而後就是一步一步深刻分析。最總要的是切勿急躁！

閱讀他人的程式碼（ 1 ）

讀懂程式碼，使心法皆爲我所用 

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

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

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

讀懂別人寫的程式碼，讓你收穫滿滿 

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

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

很是遺憾的是。上述的狀況對程式人來講很是難避免。

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

先了解系統架構與行爲模式，再細讀 

假若撰寫程式碼是程式人的重要技藝之中的一個，那麼讀懂別人的程式碼。接着加以改動，也勢必是還有一個重要的技藝。 

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

 

接觸他人的程式碼，大體上能夠分爲三種程度：一，瞭解，二，改動。擴充，三，抽取，提煉。瞭解別人的程式碼是最基礎的工做。假若不能瞭解本身要處理的程式碼，就甭論改動或擴充，更不可能去蕪存菁。從中萃取出本身所需。回收再利用別人所撰寫的程式碼。雖然說是「閱讀」 。但程式碼並不像文章或小說同樣，透過這樣的作法，即可以得到必定程度的瞭解。

閱讀文章或小說時。差點兒都是循序地閱讀，你僅僅消翻開第一頁，一行行閱讀下去就能夠。但是，有不少程式人在試着閱讀其它人的程式碼時。卻每每有不知怎樣讀起的困難。 

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

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

熟悉溝通語言與慣例用語 

不論怎樣。有些主要的準備。是閱讀他人程式碼時必須要有的。 

首先。你最好得了解程式碼寫成的程式語言。想要讀懂法文寫成的小說。總不能連法文都不懂吧。

有些狀況則很是特殊。咱們儘管不懂該程式碼撰寫所用的語言，但是因爲現代語言的高階化，而且流行的程式語言多半都是血統相近。因此即便不那麼熟悉，有時也可勉力爲之。 

除了認識所用語言以外，再來就是要先確認程式碼所用的命名慣例（命名慣例） 。瞭解命名慣例很是重要。不一樣的程式人或開發團隊，差別可能很是大。

 
這命名慣例涵蓋的範圍一般包含了變數的名稱，函式的名稱。類別（假設是物件導向的話）的名稱。原始碼檔案。甚至是專案建構文件夾的名稱。

假若使用了像設計模式之類的方法，這些名稱更有一些詳細的表述方式。 

命名慣例有點像是程式人在程式語言之上。另行建構的一組溝通行話。

程式人會透過共通約束，遵照的命名慣例，來表達一些較高階的概念。好比，有名的匈牙利式命名法，便將變數名稱以屬性，型別，說明合併在一塊兒描寫敘述。

對程式人來講。這樣的方式能夠提供更豐富的資訊，以瞭解該變數的做用及性質。 

對程式碼閱讀來講。熟悉這個作法之因此重要，是因爲當你瞭解整個系統所採用的慣例時。你便能試着以他們所共同操用的語彙來進行理解。

假若，不能瞭解其所用的慣例，那麼這些額外提供的資訊，就沒法爲你所用。像以設計模式寫成的程式碼，相同到處充滿着模式的名稱。諸如：工廠，門面。代理等等。以這些名稱指涉的類別。也直接透過名稱，表達了它們自身的做用。對於懂得這命名慣例的讀者來講。不需要深刻探索，也能很是快捕捉到這些類別的意義。

 

當你拿到一套必須閱讀的程式碼時，最好先取得命名慣例的說明文件。然而，並不是每套程式碼都附有此類的說明文件。

還有一個方式。就是本身到程式碼中。大略瀏覽一遍，有經驗的程式人可以輕易發掘出該系統所用的命名慣例。

 

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

 

掌握程式碼撰寫者的心態與習慣 

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

想要閱讀程式碼。得先試着體會程式碼做者的「心」 。想要這麼作，就得多瞭解對方所使用的語言。以及慣常運用的語彙。

在下一回中。咱們將繼續探討閱讀程式碼的相關議題。 

閱讀他人的程式碼（ 2 ）

摸清架構，即可輕鬆掌握全貌

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

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

 

閱讀程式碼的目的。在於瞭解全貌而非細節 

想要讀懂別人程式碼的根本基礎。即是瞭解對方所用的程式語言及命名慣例。

有了這個基礎以後，纔算是具有了主要的閱讀能力。

正如我以前提到的─ ─想要讀懂法文寫成的小說，總不能連法文都不懂吧。

閱讀程式碼和閱讀文學做品。都需要了解撰寫所用的語言及做者習用的語彙。 

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

就拿物件導向程式語言所寫成的系統來講，整個系統被拆解，分析成爲一個個獨立的類別。閱讀個別類別的程式碼，也許可以明確每項類別物件個別的行爲。

但對於各種別物件之間怎樣交互影響。怎樣協同工做。又很是easy陷入盲人摸象的困境。這是因爲各種別的程式碼，僅僅描寫敘述個別物件的行爲，而片斷的閱讀就僅僅能造就片面的認識。 

由上而下釐清架構後，即可輕易理解組成關係 

假設你想要跳脫困境，不想浪費大量時間閱讀程式碼。卻始終僅僅能捕捉到對系統片斷認識，就必須轉換到還有一種觀點來看待系統。

從個別的類別行爲着手，是由下至上（自下而上）的方法;在閱讀程式碼時。卻應該先採由上至下（自上而下）的方式。

對程式碼的閱讀來講，由上至下意謂着，你得先了解整個系統架構。

 

系統的架構是整個系統的骨幹，支柱。

它表現出系統最突出的特徵。知道系統架構到底屬於那一種類型。一般大大故意於瞭解系統的個別組成之間的靜態及動態關係。

有些系統因爲所用的技術或框架的關係，決定了最上層的架構。

好比，採用的Java Servlet的/ JSP的技術的應用系統。最外層的架構即是以J2EE的（或起碼的J2EE中的Web容器）爲根本。 

使用的Java Servlet的/ JSP的技術時，決定了某些組成之間的關係。

好比， Web容器根據web.xml中的內容加載所有的Servlets 。聽衆，以及過濾器。每當語境發生事件（好比初始化）時，它便會通知監聽類別。

每當它收到來自client的請求時，便會依循設定的所有過濾器鏈，讓每個過濾器都有機會檢查並處理此一請求，最後再將請求導至用來處理該請求的Servlet的。 

當咱們明確某個系統採用這種架構時，便可以很是easy地知道各個組成之間的關係。即便咱們還不知道到底有多少Servlets 。但咱們會知道，每當收到一個請求時。老是會有個相相應的server來處理它。當想要關注某個請求怎樣處理時。我應該去找出這個請求相應的server。 

瞭解架構。必須要加上層次感 

相同的，以爪哇寫成的網頁應用程式中，或許會應用諸如Struts的之類的的MVC框架。以及像Hibernate的這種資料存取框架。它們都可以視爲最基本的架構下的較次級架構。

而各個應用系統，甚至有可能在Struts的及休眠之下，創建自有的更次級的架構。 

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

這是一個很是重要的關鍵，當你試着進到最細節處以前，應該先試着找出參與的角色，及他們之間的關係。好比，對事件驅動式的架構而言，有3個很是重要的角色。

一個是事件處理的分派器（事件調度） ，一個是事件產生者（事件發生器） ，還有一個則是事件處理器（事件處理程序） 。 

事件產生器產生事件，並送至事件分派器，而事件分派器負責找出各事件相相應的事件處理器，並且轉交該事件，並命令事件處理器加以處理。

像的圖形用戶界面的Windows應用程式。即是採用事件驅動式的架構。 

當你知道此類的應用程式皆爲事件驅動式的架構時，你便可以進一步得知，在這種架構下會有3種基本的角色。儘管或許還不清楚整個系統中，到底會需要處理多少事件的類型，但對你而言。已經創建了對系統全貌最概觀的認識。 

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

 

探索架構的第一件事：找出系統怎樣初始化 

有經驗的程式人。對於時常被運用的架構都很是熟悉。常常僅僅需要瞧上幾眼。就能明確一個系統所用的架構。天然就行直接聯想到當中會存在的角色，以及角色間的關係。然而，並不是每個系統所用的架構，都是大衆所熟悉，或是一眼能夠望穿的。

這時候，你需要探索。目標相同要放在界定當中的角色。以及角色間的靜態，動態關係。 

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

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

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

閱讀他人的程式碼（ 3 ） 

優質工具在手，讀懂程式非難事

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

閱讀程式碼的動做，可以是很是原始的。利用最簡單的文字編輯器。逐一開啓原始碼。而後憑藉着一己的組織能力，在不一樣的程式碼間跳躍，拼湊出腦中想要構建的圖像。 
只是，系統的複雜度每每超過人腦的負荷。

閱讀程式碼的時候，你會需要不少其它工具提供協助。使用好的整合式開發環境（ IDE ）的或文字編輯器，就能提供最主要的幫助。

 

善用文字編輯器或IDE中。加速解讀程式碼 

不少文字編輯器提供了常見程式語言的語法及keyword標示功能。這對於閱讀來講，絕對能夠起很是大的做用。有些文字編輯器（好比我常用的編輯器及偶而使用的記事本+ + ），甚至能夠本身主動列出某個原始檔中所有定義的函式清單，更贊成你直接從清單中選擇函式。直接跳躍到該函式的定義位置。

這對於閱讀程式碼的人來講，就提供了極佳的便利性。 

因爲在閱讀程式碼時，最常作的事。就是隨着程式中的某個控制流，將閱讀的重心，從某個函式移至它所呼叫的還有一個函式。

因此對程式人來講。閱讀程式碼時最常作的事之中的一個就是：找出某個函式位在那一個原始檔裏，接着找到該函式所在的位置。

 

好的的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文件，已經爲你創建起在各個原始碼檔案片斷間跳躍的鏈結。 

htags工具首先爲你找出所有定義的Main （ ）函式的檔案。並且列出所在的函式。

找出的Main （ ）函式，時常是閱讀程式碼的第一步，因爲主要（ ）函式是程式的主要入口點，所有的動做皆由此啓動。它是一切事物的源頭。

 
憑藉htags製做的的HTML文件，你可以輕易地點擊超連結，直接進到的Main （ ）函式所在的程式碼片斷。

 


當咱們檢視上述原始碼時。發現av_register_all （ ）是個陌生，沒法瞭解的事物，而想要搞懂它究竟是什麼，可以再繼續點擊這個函式。這真是太方便了！

閱讀至此，你會猛然發現， gtags彷彿就是爲了閱讀程式碼而專門量身打造的利器。 

閱讀他人的程式碼（ 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這個keyword來修飾。因此，不管是利用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 （ ） 

這部分必須要留意幾個重點。首先。應該一邊閱讀，一邊記錄文件。因爲人的記憶力一般有限，對於陌生的事物更是easy遺忘，所以邊閱讀邊記錄，是很是好的輔助。 
再者。因爲咱們採取由上而下的方式，從一個點再分支出去成爲多個點。所以。一般也會以樹狀的方式記錄。除此以外，每次僅僅試着往下探索一層。從的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專案，因爲程式碼中混合了不一樣的來源，而呈現風格不一致的狀況。 

我在閱讀非本身所寫的程式碼時，會觀察原做者寫做的習慣。藉以相應到腦中所記憶的多種寫做模型。

在閱讀的過程當中。讀完幾行程式碼，我會試着猜測原做者在寫下這段程式碼時的心境。

他寫下這段程式碼的用意是什麼？爲何他會採取這種寫法？順着原做者的思考理路閱讀，本身的思考才幹更貼近對方寫做當時的想法。 

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

從程式碼着手認識做者獨有的風格，進而見賢思齊 

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

物件導向的基本教義派，老是會以他心中認爲最優雅的物件導向方式來撰寫程式。

而閱讀慣用。善用設計模式的程式人所寫下的程式碼時，不難推想出他會在各類常見的應用情境下，套用哪些模式。

 

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

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

這也算是閱讀他人程式碼時的一項樂趣。 

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