正在困擾如何能深一步的學習技術時發現了這篇文章,實在是寫的好,讓人有茅塞頓開之感web
如何閱讀他人的程序代碼數據庫
文/王建興設計模式
做者簡介: 王建興,清華大學資訊工程系的博士研究生,研究興趣包括計算機網絡、點對點網絡、分佈式網絡管理、以及行動式代理人,專長則是Internet應用系統的開發。曾參與過的開發項目性質十分普遍並且不一樣,從ERP、PC Game到P2P網絡電話都在他的涉獵範圍以內。網絡
1、讀懂程序代碼,使心法皆爲我所用數據結構
程序代碼是別人寫的,只有原做者才真的瞭解程序代碼的用途及涵義。許多程序人內心都有一種不自覺的恐懼感,深怕被迫去碰觸其餘人所寫的程序代碼。可是,與其抗拒接收別人的程序代碼,不如完全瞭解相關的語言和慣例,當成是培養自我實力的基石。多線程
對大多數的程序人來講,撰寫程序代碼或許是使人開心的一件事情,但我相信,有更多人視閱讀他人所寫成的程序代碼爲畏途。許多人寧肯本身從新寫過一遍程序代碼,也不肯意接收別人的程序代碼,進而修正錯誤、維護它們、甚至增強功能。架構
這其中的關鍵究竟在何處呢?如果一語道破,其實也很簡單,程序代碼是別人寫的,只有原做者才真的瞭解程序代碼的用途及涵義。許多程序人內心都有一種不自覺的恐懼感,深怕被迫去碰觸其餘人所寫的程序代碼。這是來自於人類心裏深處對於陌生事物的原始恐懼。框架
讀懂別人寫的程序代碼,讓你收穫滿滿編輯器
不過,基於許多現實的緣由,程序人時常受迫要去接收別人的程序代碼。例如,同事離職了,必須接手他遺留下來的工做;也有可能你是剛進部門的菜鳥,而同事經驗值夠了、升級了,風水輪流轉,一代菜鳥換菜鳥。甚至,你的公司所承接的項目,必須接手或是整合客戶前一個廠商所遺留下來的系統,大家手上只有那套系統的原始碼(運氣好時,還有數量不等的文件)。分佈式
諸如此類的故事,其實時常在程序人身邊或身上持續上演着。許多程序人都將接手他人的程序代碼,當作一件悲慘的事情。每一個人都不想接手別人所撰寫的程序代碼,由於不想花時間去探索,寧肯將生產力花在產生新的程序代碼,而不是耗費在瞭解這些程序代碼上。
很遺憾的是,上述的狀況對程序人來講很難避免。咱們老是必須碰觸到其餘人所寫成的程序代碼,甚至必須瞭解它、加以修改。對於這項需求,在現今開放原始碼的風氣如此盛行的今日,正如以前的「程序設計2.0」文中所提到的,你能夠透過開放原始碼學習到新的技術、學習到高手的架構設計,大幅提升學習的效率及效果。你甚至能夠直接自開放原始碼項目中抽取、提煉出本身所需的程序代碼,站在巨人的肩膀上,直接由彼端得到所需的生產力。從這個觀點來看,讀懂別人所寫的程序代碼,就再也不只是從負面觀點的「被迫接收」,而是極具正面價值的「汲取養份」。
先了解系統架構與行爲模式,再細讀
假若撰寫程序代碼是程序人的重要技藝之一,那麼讀懂別人的程序代碼、接着加以修改,也勢必是另外一個重要的技藝。
若是你不能熟悉這項工做,不只在遭逢你所不肯面對的局面時,沒法解決眼前接手他人程序代碼的難題,更重要的是,當你看着眼前現成的程序代碼,殊不知如何從中擷取本身所需,致使最後只能入寶山空手回,望之興嘆。
接觸他人的程序代碼,大體上能夠分爲三種程度:1、瞭解,2、修改、擴充,3、抽取、提煉。
瞭解別人的程序代碼是最基礎的工做,假若不能瞭解本身要處理的程序代碼,就甭論修改或擴充,更不可能去蕪存菁,從中萃取出本身所需,回收再利用別人所撰寫的程序代碼。
雖然說是「閱讀」,但程序代碼並不像文章或小說同樣,透過這種作法,便可以得到必定程度的瞭解。閱讀文章或小說時,幾乎都是循序地閱讀,你只消翻開第一頁,一行行閱讀下去便可。可是,有許多程序人在試着閱讀其餘人的程序代碼時,卻每每有不知如何讀起的困難。
或許找到系統的第一頁(也就是程序代碼執行的啓始點)並不難,可是複雜度高的系統,有時十分龐大,有時千頭萬緒。
從程序代碼的啓始點開始讀起,一來要循序讀完全部的程序代碼曠日費時,二來透過這種方式來了解系統,很難在腦中構建出系統的面貌,進而瞭解到系統真正的行爲。因此,閱讀程序代碼的重點,不在於讀完每一行程序代碼,而是在於有效率地透過探索及閱讀,從而瞭解系統的架構及行爲模式。以便在你須要瞭解任何片斷的細節實做時,可以很快在腦上對映到具體的程序代碼位置,直到那一刻,纔是細讀的時機。
熟悉溝通語言與慣例用語
不論如何,有些基本的準備,是閱讀他人程序代碼時必需要有的。
首先,你最好得了解程序代碼寫成的程序語言。想要讀懂法文寫成的小說,總不能連法文都不懂吧。有些狀況則很特殊。咱們雖然不懂該程序代碼撰寫所用的語言,可是由於現代語言的高階化,並且流行的程序語言多半都是血統相近,因此即便不那麼熟悉,有時也可勉力爲之。
除了認識所用語言以外,再來就是要先確認程序代碼所用的命名慣例(naming convention)。瞭解命名慣例很重要,不一樣的程序人或開發團隊,差別可能很大。
這命名慣例涵蓋的範圍一般包括了變量的名稱、函式的名稱、類別(若是是面向對象的話)的名稱、原始碼檔案、甚至是項目建構目錄的名稱。假若使用了像設計模式之類的方法,這些名稱更有一些具體的表述方式。
命名慣例有點像是程序人在程序語言之上,另行建構的一組溝通行話。程序人會透過共通約束、遵照的命名慣例,來表達一些較高階的概念。例如,有名的匈牙利式命名法,便將變量名稱以屬性、型別、說明合併在一塊兒描述。對程序人來講,這種方式可以提供更豐富的信息,以瞭解該變量的做用及性質。
對程序代碼閱讀來講,熟悉這個作法之因此重要,是由於當你瞭解整個系統所採用的慣例時,你便能試着以他們所共同操用的語彙來進行理解。假若,不能瞭解其所用的慣例,那麼這些額外提供的信息,就沒法爲你所用。像以設計模式寫成的程序代碼,一樣到處充滿着模式的名稱,諸如:Factory、Facade、Proxy等等。以這些名稱指涉的類別,也直接透過名稱,表達了它們自身的做用。對於懂得這命名慣例的讀者來講,不須要深刻探索,也能很快捕捉到這些類別的意義。
當你拿到一套必須閱讀的程序代碼時,最好先取得命名慣例的說明文件。然而,並非每套程序代碼都附有此類的說明文件。另外一個方式,就是本身到程序代碼中,大略瀏覽一遍,有經驗的程序人能夠輕易發掘出該系統所用的命名慣例。
常見的命名方式不脫那幾類,這時候經驗就很重要,假若你知道的慣例越多,就越能輕易識別他人所用的慣例。若是運氣很糟,程序代碼所用的慣例是前所未見的,那麼你也得花點時間概括,憑本身的力量找出這程序代碼命名上的規則。
掌握程序代碼撰寫者的心態與習慣
大多數的程序代碼,基本上都依循一致的命名慣例。不過運氣更差的時候,一套系統中可能會充斥着多套命名慣例。這有多是由於開發團隊由多組人馬所構成,每組人馬都有不一樣的文化,而在項目開發管理又沒有管控得宜所形成。最糟的狀況,程序代碼徹底沒有明顯的慣例可言,這時候閱讀的難度就更高了。
想要閱讀程序代碼,得先試着體會程序代碼做者的「心」。想要這麼作,就得多瞭解對方所使用的語言,以及慣常運用的語彙。在下一回中,咱們將繼續探討閱讀程序代碼的相關議題。
2、摸清架構,即可輕鬆掌握全貌
在本文中,咱們的重點放在:要了解一個系統,最好是採起由上至下的方式。先試着捕捉系統架構性的觀念,不要過早鑽進細節,由於那一般對於你瞭解全貌,沒有多大的幫助。閱讀程序代碼不須要從第一行讀起,咱們的目的並非在於讀遍每一段程序代碼。
基於許多緣由,程序人須要閱讀其餘人所寫成的程序代碼。而對程序設計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種主要的角色。雖然也許還不清楚整個系統中,究竟會須要處理多少事件的類型,但對你而言,已經創建了對系統全貌最概觀的認識。
雖然你還不清楚全部的細節,但諸如確切會有那些事件類型之類的信息,在此刻還不重要──不要忘了,咱們採起的是由上而下的方式,要先摸清楚主建築結構,至於壁紙的花色怎麼處理,那是到了尾聲時纔會作的事。
探索架構的第一件事:找出系統如何初始化
有經驗的程序人,對於時常被運用的架構都很熟悉。經常只須要瞧上幾眼,就能明白一個系統所用的架構,天然就可以直接聯想到其中會存在的角色,以及角色間的關係。
然而,並非每一個系統所用的架構,都是大衆所熟悉,或是一眼可以望穿的。這時候,你須要探索。目標一樣要放在界定其中的角色、以及角色間的靜態、動態關係。
不論某個系統所採用的架構是否爲大部分人所熟知的,在試着探索一個系統的長相時,咱們應該找出來幾個答案,瞭解在它所用的架構下,下列這件事是如何被完成的:1、系統如何初始化,2、與這個系統相接的其餘系統(或用戶)有那些,而相接的接口又是什麼;3、系統如何反應各類事件,4、系統如何處理各類異常及錯誤。
系統如何初始化是很重要的一件事,由於初始化是爲了接下來的全部事物而作的準備。從初始化的方式、內容,能知道系統作了什麼準備,對於系統會有什麼行爲展示,也就能得窺一二了。
之因此要了解與系統相接的其餘系統(或用戶),爲的是要界定出系統的邊界。其餘的系統可能會提供輸入給咱們所探索的系統,也可能接收來自這系統的輸出,瞭解這邊界所在,才能肯定系統的外觀。
而系統所反應的事件類型、以及如何反應,基本上就表明着系統自己的主要行爲模式。最後,咱們必須瞭解系統處理異常及錯誤的方式,這一樣也是系統的重要行爲,但容易被忽略。
以前,咱們提到必須先具有一個系統的語言基礎,纔可以進一步加以閱讀,而在本文中,咱們的重點放在:要了解一個系統,最好是採起由上至下的方式。先試着捕捉系統架構性的觀念,不要過早鑽進細節,由於那一般對於你瞭解全貌,沒有多大的幫助。
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似乎就是爲了閱讀程序代碼而專門量身打造的利器。
4、望文生義,進而推敲組件的做用
先創建系統的架構性認識,而後透過名稱及命名慣例,就能夠推測出各組件的做用。例如:當Winamp嘗試着初始化一個Plug-In時,它會呼叫這個結構中的init函式,以便讓每一個Plug-In程序有機會初始化本身。當Winamp打算結束本身或結束某個Plug-In的執行時,便會呼叫quit函式。
在閱讀程序代碼的細節以前,咱們應先試着捕捉系統的運做情境。在採起由上至下的方式時,系統性的架構是最頂端的層次,而系統的運做情境,則是在它之下的另外一個層次。
好的說明文件難求,拼湊故事的能力很重要
有些系統提供良善的說明文件,也許還利用UML充分描述系統的運做情境。那麼對於閱讀者來講,從系統的分析及設計文件着手,即是快速瞭解系統運做情境的一個途徑。
可是,並非每一個軟件項目都伴隨着良好的系統文件,而許多極具價值的開放原始碼項目,也時常不具有此類的文件。對此,閱讀者必須嘗試自行捕捉,並適度地記錄捕捉到的運做情境。
我喜歡將系統的運做情境,比擬成系統會上演的故事情節。在閱讀細節性質的程序代碼前,先知道系統究竟會發生那些故事,是必備的基本功課。你能夠利用熟悉或者本身發明的表示工具,描述你所找到的情境。甚至能夠只利用簡單的列表,直接將它們列出。只要可以達到記錄的目的,對程序代碼閱讀來講,都可以提供幫助。或者,你也能夠利用UML中的類別圖、合做圖、循序圖之類的表示方法,作出更詳細的描述。
當你可以列出系統可能會有的情境,表示你對系統所具有的功能,以及在各類狀況下的反應,都具有歸納性的認識。以此爲基礎,即可在任何須要的時候,鑽進細節處深刻了解。
探索架構的第一步──找到程序的入口
在以前,咱們在一個開發項目中,曾經須要將系統所獲得的MP3音訊文件,放至iPod這個極受歡迎的播放設備中。
雖然iPod自己也能夠作爲可移動式的儲存設備,但並非單純地將MP3檔案放到iPod中,就可讓iPod的播放器認得這個檔案,甚至可以加以播放。
這是由於iPod利用一個特殊的檔案結構(iTunes DB),記錄播放器中可供播放的樂曲、播放列表以及樂曲信息(例如專輯名稱、樂曲長度、演唱者等)。爲了瞭解而且試着重複使用既有的程序代碼,咱們找到了一個Winamp的iPod插件(Plug-In)。
Winamp是我的計算機上極受歡迎的播放軟件,而咱們找到的插件,能讓Winamp直接顯示鏈接至計算機的iPod中的歌曲信息,而且容許Winamp直接播放。
咱們追蹤與閱讀這個插件的思路及步驟以下,首先,咱們要先了解插件的系統架構。很明顯的,大概瀏覽過原始碼後,咱們注意到它依循着WinAmp爲Plug-In程序所制定的規範,也就是說,它是實做成Windows上的DLL,而且透過一個叫作winampGetMediaLibraryPlugin的DLL函式,提供一個名爲winampMediaLibraryPlugin的結構。
當咱們不清楚系統的架構究竟爲什麼時,咱們會試着探索,而第一步,即是找到程序的入口。如何找到呢?這會依程序的性質不一樣而有所差異。
對一個自己就是可獨立執行的程序來講,咱們會找啓動程序的主要函式,例如對C/C++來講就是main(),而對Java來講,即是static void main()。在找到入口後,再逐一追蹤,摸索出系統的架構。
但有時,咱們所欲閱讀的程序代碼是類別庫或函式庫,它只是用來提供多個類別或函式供客戶端程序(Client Program)使用,自己並不具單一入口,此類的程序代碼具備多重的入口──每一個容許客戶端程序呼叫的函式或類別,都是它可能的入口。
例如,對WinAmp的iPod Plug-In來講,它是一個DLL形式的函式庫,因此當咱們想了解它的架構時,必需要先找出它對外提供的函式,而對Windows DLL來講,對外提供的函式,皆會以dllexport這個關鍵詞來修飾。因此,不管是利用grep或gtags之類的工具,咱們能夠很快從原始碼中,找到它只有一個DLL函式(這對咱們而言,真是一個好消息),而這個函式即是上述的winampGetMediaLibraryPlugin。
系統多會採用相同的架構處理Plug-In程序
若是經驗不夠的話,也許沒法直接猜出這個函式的做用。
不過,若是你是個有經驗的程序人,多半能從函式所回傳的結構,猜出這個函式實際的用途。而事實上,當你已經知道它是一個Plug-In程序時,就應該要明白,它可能採用的,就是許多系統都採用的相同架構處理Plug-In程序。
當一個系統採用所謂Plug-In形式的架構時,它一般不會知道它的Plug-In究竟會怎麼實做、實做什麼功能。它只會規範Plug-In程序須要知足某個特定接口。當系統初始化時,全部的Plug-In均可以依循相同的方式,向系統註冊,合法宣示本身的存在。
雖然系統並不確切知道Plug-In會有什麼行爲展示,可是由於它制定了一個標準的接口,因此係統仍然能夠預期每一個Plug-In可以處理的動做類型。這些動做具體上怎麼執行,對系統來講並不重要。這也正是面向對象程序設計中的「多型」觀念。
隨着實務經驗,概括常見的架構模式
我想表達的重點,是當你「涉世越深」以後,所接觸的架構越多,就越能舉一反三。只須要瞧上幾眼,就能明白系統所用的架構,天然就可以直接聯想到其中可能存在的角色,以及角色間的關係。
像上述的Plug-In程序手法,時常能夠在許多容許「外掛」程序代碼的系統中看到。因此,有經驗的閱讀者,多半可以當即反應,知道像Winamp這樣的系統,應該是讓每一個Plug-In程序,都寫成DLL函式庫。
而每一個Plug-In的DLL函式庫中,都必須提供winampGetMediaLibraryPlugin()這個函式(若是你熟悉Windows的程序設計,你會知道這是利用LoadLibrary()和GetProcAddress()來達成的一種多型手法)。若是你熟悉設計模式,你更會知道這是Simple Factory Method這個設計模式的運用。
winampGetMediaLibraryPlugin()所回傳的winampMediaLibraryPlugin結構,正好就描述了每一個Winamp Plug-In的實做內容。
善用名稱可加速瞭解
利用gtags這個工具,咱們當即發現,這個Plug-In它所定義的init、quit、PluginMessageProc這三個名稱,都是函式名稱。這暗示在多型的做用下,它們都是在某些時間點,會由Winamp核心本體呼叫的函式。
名稱及命名慣例是很重要的。看到「init」,咱們會知道它的做用多半是進行初始化的動做,而「quit」大概就是結束時處理函式,而PluginMessageProc多半就是各類訊息的處理程序(Proc一般是procedure的簡寫,因此PluginMessageProc意指Plugin Message Procedure)了。
「望文生義」很重要,咱們看到函式的名稱,就能夠猜測到它所表明的做用,例如:當Winamp嘗試着初始化一個Plug-In時,它會呼叫這個結構中的init函式,以便讓每一個Plug-In程序有機會初始化本身;當Winamp打算結束本身或結束某個Plug-In的執行時,便會呼叫quit函式。當Winamp要和Plug-In程序溝通時,它會發送各類不一樣的訊息至Plug-In,而Plug-In程序必須對此作出迴應。
咱們甚至不須要檢視這幾個函式的內容,就能夠作出推測,而這樣的假設,事實上也是正確的。
5、找到程序入口,再由上而下抽絲剝繭
根據須要決定展開的層數,或展開特定節點,並記錄樹狀結構,而後適度忽略不須要了解的細節─這是一個很重要的態度。由於你不會一次就須要全部的細節,閱讀都是有目的的,每次的閱讀也許都在探索程序中不一樣的區域。
探索系統架構的第一步,就是找到程序的入口點。找到入口點後,多半採起由上而下(Top-Down)的方式,由最外層的結構,一層一層逐漸探索愈來愈多的細節。
咱們的開發團隊曾針對Winamp的iPod plug-in進行閱讀及探索,不只找到入口點,也找出、並理解它最根本的基礎架構。從這個入口點,能夠往下再展開一層,分別找到三個重要的組成及其意義:
● init():初始化動做
● quit():終止化動做
● PluginMessageProc():以訊息的方式處理程序所必須處理的各類事件
展開的同時,隨手記錄樹狀結構
當咱們從一個入口點找到三個分支後,能夠順着每一個分支再展開一層,因此分別繼續閱讀init、quit、以及PluginMessageProc的內容,並試着再展開一層。閱讀的同時,你能夠在文件中試着記錄展開的樹狀結構。
● init():初始化動做
● itunesdb_init_cc():創建存取iTunes database的同步對象
● 初始化數據結構
● 初始化GUI元素
● 加載設定
● 創建log檔
● autoDetectIpod():偵測iPod插入的線程
● quit():終止化動做
● itunesdb_del_cc():終止存取iTunes database的同步對象
● 關閉log檔
● 終止化GUI元素
● PluginMessageProc():以訊息的方式處理程序所必須面臨的各類事件
● 執行所鏈接之iPod的MessageProc()
這部分必需要留意幾個重點。首先,應該一邊閱讀,一邊記錄文件。由於人的記憶力一般有限,對於陌生的事物更是容易遺忘,所以邊閱讀邊記錄,是很好的輔助。
再者,由於咱們採起由上而下的方式,從一個點再分支出去成爲多個點,所以,一般也會以樹狀的方式記錄。除此以外,每次只試着往下探索一層。從init()來看你便會明白。如下試着摘要init()的內容:
int init() {
itunesdb_init_cc();
currentiPod=NULL;
iPods = new C_ItemList;
…略
conf_file=(char*)SendMessage(plugin.hwndWinampParent,WM_WA_IPC,0,IPC_GETINIFILE);
m_treeview = GetDlgItem(plugin.hwnd LibraryParent,0x3fd);
//this number is actually magic :)
…略
g_detectAll = GetPrivateProfileInt("ml_ipod", "detectAll",0,conf_file)!=0;
…略
g_log=GetPrivateProfileInt("ml_ipod","log",0,conf_file)!=0;
…略
g_logfile=fopen(g_logfilepath,"a");
…略
autoDetectIpod();
return 0;
}
由於咱們只試着多探索一層,而目的是但願發掘出下一層的子動做。因此在init()中看到像「itunesdb_init_cc();」這樣的函數調用動做時,咱們知道它是在init()之下的一個獨立子動做,因此能夠直接將它列入。可是當看到以下的程序行:
currentiPod=NULL;
iPods = new C_ItemList;
咱們並不會將它視爲init()下的一個獨立的子動做。由於好幾行程序,才構成一個具備獨立抽象意義的子動做。例如以上這兩行構成了一個獨立的抽象意義,也就是初始化所需的數據結構。
理論上,原來的程序撰寫者,有可能撰寫一個叫作init_data_structure()的函式,包含這兩行程序代碼。這樣作可讀性更高,然而基於種種理由,原做者並無這麼作。身爲閱讀者,必須自行解讀,將這幾行合併成單一個子動做,並賦予它一個獨立的意義──初始化數據結構。
沒法望文生義的函式,先試着預看一層
對於某些不明做用的函式叫用,不是望其文便能生其義的。當咱們看到「itunesdb_init_cc()」這個名稱時,咱們或許能從「itunesdb_init」的字眼意識到這個函式和iPod所採用的iTunes database的初始化有關,但「cc」卻實在使人費解。爲了理解這一層某個子動做的真實意義,有時免不了要往前多看一層。
原來它是用來初始化同步化機制用的對象。做用在於這程序必定是用了某個內部的數據結構來儲存iTunes database,而這數據結構有可能被多線程存取,因此必須以同步對象(此處是Windows的Critical Section)加以保護。
因此說,當咱們試着以樹狀的方式,逐一展開每一個動做的子動做時,有時必須多看一層,才能真正瞭解子動做的意義。由於有了這樣的動做,咱們能夠在展開樹狀結構中,爲itunesdb_init_cc()附上補充說明:創建存取itunes database的同步對象。這麼一來,當咱們在檢視本身所寫下的樹狀結構時,就能輕易一目瞭然的理解每一個子動做的真正做用。
根據須要瞭解的粒度,決定展開的層數
咱們究竟須要展開多少層呢?這個問題和閱讀程序代碼時所需的「粒度(Granularity)」有關。若是咱們只是須要歸納性的瞭解,那麼也許展開兩層或三層,就可以對程序有基礎的認識。假若須要更深刻的瞭解,就會須要展開更多的層次才行。
有時候,你並非一視同仁地針對每一個動做,都展開到相同深度的層次。也許,你會基於特殊的需求,專門針對特定的動做展開至深層。例如,咱們閱讀Winamp iPod plug-in的程序目錄,實際上是想從中瞭解究竟應該如何存取iPod上的iTunes DB,使咱們可以將MP3歌曲或播放列表加至此DB中,並於iPod中播放。
當咱們層層探索與分解以後,找到了parseIpodDb(),從函式名稱判斷它是咱們想要的。由於它表明的正是parse iPod DB,正是咱們這次閱讀的重點,也就達成閱讀這程序代碼的目的。
咱們強調一種不一樣的作法:在閱讀程序代碼時,多半採起由上而下的方式;而本文建議了一種記錄閱讀的方式,就是試着記錄探索追蹤時層層展開的樹狀結構。你能夠視本身須要,瞭解的深刻程度,再決定要展開的層數。你更能夠依據特殊的須要,只展開某個特定的節點,以探索特定的細目。
適度地忽略不須要了解的細節,是一個很重要的態度,由於你不會一次就須要全部的細節,閱讀都是有目的的。每次的閱讀也許都在探索程序中不一樣的區域;而每次探索時,你均可以增補樹狀結構中的某個子結構。漸漸地,你就會對這個程序更加的瞭解。
6、閱讀的樂趣:透過程序代碼認識做者
即使每一個人的寫做模式多半受到他人的影響,程序人一般仍是會融合多種風格,而成爲本身獨有的特點,若是你知道做者程序設計的偏好,閱讀他的程序代碼就更駕輕就熟。
閱讀程序代碼時,多半會採起由上而下、抽絲剝繭的方式。透過記錄層層展開的樹狀結構,程序人能夠逐步地創建起對系統的架構觀,並且能夠依照須要的粒度(Granularity),決定展開的層次及精緻程度。
創建架構觀點的認識是最重要的事情。雖然這一系列的文章前提爲「閱讀他人的程序代碼」,但咱們真正想作的工做,並不在於完全地詳讀每一行程序代碼的細節,而是想要透太重點式的程序代碼「摘讀」,達到對系統所需程度的瞭解。每一個人在閱讀程序代碼的動機不盡相同,須要瞭解的程度也就有深淺的分別。只有極爲少數的狀況下,你纔會須要細讀每一行程序代碼。
閱讀程序代碼是新時代程序人必備的重要技能
這一系列的文章至此已近尾聲,回顧曾探討的主題,咱們首先研究了閱讀程序代碼的動機。尤爲在開放原始碼的風氣如此之盛的狀況下,妥善利用開放原始碼所提供的資源,不只可以更快學習到新的技術,同時在原始碼版權合適時,還能夠直接利用現成的程序代碼,大幅地提升開發階段的生產力。因此,閱讀程序代碼儼然成爲了新時代程序人必備的重要技能之一。
接着,咱們提到了閱讀程序代碼前的必要準備,包括了對程序語言、命名慣例的瞭解等等。在此以後,咱們反覆提起了「由上而下」的閱讀方向的重要性。
由上而下的閱讀方式,是由於咱們重視架構更勝於細節。從最外層的架構逐一貫內探索,每往內探索一層,咱們瞭解系統的粒度就增長了一個等級。當你識別出系統所用的架構時,便可以輕易瞭解在這個架構下會有的角色,以及它們之間的動態及靜態的關係。如此一來,許多信息便不言可喻,毋需額外花費力氣,便可以快速理解。
好的名稱可以摘要性地點出實體的做用
追蹤原始碼時,當然能夠用原本的方式,利用編輯器開啓所需的檔案,而後利用編輯器提供的機制閱讀,可是假若可以善用工具,閱讀程序代碼的效率及質量都能大大提高。在本系列文章中,咱們介紹了一些工具,或許你還能夠在坊間找到其餘更有用的工具。
我在這一系列的文章中,實際帶着你們閱讀、追蹤了一個名爲ml_pod的開放原始碼項目。它是一個Winamp的iPod plug-in程序。在追蹤的過程當中,咱們試着印證這一系列文中所提到的觀念及方法。咱們採用逐漸開展的樹狀結構來記錄追蹤的過程,並藉以創建起對系統的概觀認識。
就原始碼的閱讀來講,以前的討論涉及了工具面及技巧面。但還有一些主題不在這兩個範疇以內,例如,善用名稱賦予你的提示。名稱作爲隱喻(Metaphor)的做用很大,好的名稱可以摘要性地點出實體的做用,例如咱們看到autoDetectIpod(),天然而然可以想象它的做用在於自動(Auto)偵測(Detect)iPod的存在。
咱們在展開樹狀結構時,有時候須要預看一層,有時卻不須要這麼作,即可獲得印證。程序人都會有慣用的名稱以及組合名稱的方法,假若可以從名稱上理解,便毋需鑽進細節,能夠省去至關多的時間。例如,當咱們看到parseIpodDb()時,即可以輕易瞭解它是剖析(Parse)iPod的數據庫(DB),所以便不須要當即鑽進parseIpodDb()中查看底細。
儘管如此,可否理解程序人命名的用意,和自身的經驗以及是否瞭解原做者的文化背景,是息息相關的。
命名自己就是一種文化產物。不一樣的程序人文化,就會衍生出不一樣的命名文化。當你本身的經驗豐富,看過及接觸過的程序代碼也多時,對於名稱的感覺及聯想的能力天然會有不一樣。
這種感覺和聯想的能力,究竟應該如何精進,很難具體描述。就我我的的經驗,多觀察不一樣命名體系的差別,而且嘗試概括彼此之間的異同,有助於更快地提高對名稱的感覺及聯想力。
轉換立場,理解做者的思考方式
除了工具及技巧以外,「想要閱讀程序代碼,得先試着閱讀寫這個程序代碼的程序人的心。」這句話說來十分抽象,或許也使人難以理解。
當你在閱讀一段程序代碼時,或許能夠試着轉換本身的立場,從旁觀者的角度轉換成爲寫做者的心態,揣摩原做者的心理及處境。當你試着設身處地站在他的立場,透過他的思考方式來閱讀、追蹤他所寫下的程序代碼,將會感受更加流暢。
許多軟件項目,都不是由單一程序人所獨力完成。所以,在這樣的項目中,便有可能呈現多種不一樣的風格。
許多項目會由架構師決定主體的架構及運做,有既定實施的命名慣例,及程序設計須要遵照方針。在多人開發的模式下,越是好的軟件項目,越看不出某代碼段到底是由誰所寫下的。
不過,有些開放原始碼的項目,每每又整合了其餘開放原始碼的項目。有的時候,也很難求風格的統一,便會出現混雜的狀況。比如以前提到的ml_pod項目,由於程序代碼中混合了不一樣的來源,而呈現風格不一致的狀況。
我在閱讀非本身所寫的程序代碼時,會觀察原做者寫做的習慣,藉以對應到腦中所記憶的多種寫做模型。在閱讀的過程當中,讀完幾行程序代碼,我會試着猜測原做者在寫下這段程序代碼時的心境。他寫下這段程序代碼的用意是什麼?爲何他會採起這樣的寫法?順着原做者的思考理路閱讀,本身的思考才能更貼近對方寫做當時的想法。
當你短暫化身爲原做者時,才能更輕易的理解他所寫下的程序代碼。
若是你能知道原做者的背景,程序設計時的偏好,閱讀他的程序代碼,就更能駕輕就熟了。
從程序代碼着手認識做者獨有的風格,進而見賢思齊
我在閱讀別人寫下的程序代碼時,我會試着猜測,原做者到底是屬於那一種「流派」呢?每一個人都有本身獨特的寫做模式,即使每一個人的寫做模式多半受到他人的影響──不管是書籍的做者、學習過程當中的指導者,或一同參與項目的同儕,但每一個程序人一般會融合多種風格,而成爲本身獨有的風格。
面向對象的基本教義派,老是會以他心中以爲最優雅的面向對象方式來撰寫程序。而閱讀慣用、善用設計模式的程序人所寫下的程序代碼時,不難推想出他會在各類常見的應用情境下,套用哪些模式。
有些時候,在閱讀之初,你並不知道原做者的習性跟喜愛,甚至你也不知道他的功力。可是,在閱讀以後,你會慢慢地從一個程序人所寫下的程序代碼,開始認識他。
你或許會在閱讀他人的程序代碼時,發現使人拍案叫絕的技巧或設計。你也有可能在閱讀的同時,發現原做者所留下的缺失或寫做時的缺點,而暗自警戒於心。這也算是閱讀他人程序代碼時的一項樂趣。
當你從視閱讀他人的程序代碼爲畏途,轉變成爲能夠從中獲取樂趣的時候,我想,你又進到了另外一個境界。