【文章內容簡介】 搜尋更有效率 grep按雖然好用，但是仍然有一些不足之處。第一個缺點在于它并不會為所搜尋的原始碼檔案索引。每當你搜尋時，它都會逐一地找出所有的檔案，并且讀取其中的所有內容，過濾出滿足指定條件的檔案。當專案的原始碼數(shù)量太大時，就會產生搜尋效率不高的問題。 第二個缺點是它只是一個單純的文字檔搜尋工具，本身并不會剖析原始碼所對應的語言語法。當我們只想針對“函式”名稱進行搜尋時，它有可能將注解中含有該名稱的原始碼，也一并找了出來。 針對grep按的缺點，打算閱讀他人程式碼的程式人，可以考慮使用像是gtags這樣子的工具。 gtags是源代碼的GNU全局標記系統(tǒng)，它不只搜尋文字層次，而且因為具備了各種語言的語法剖析器，所以在搜尋時，可以只針對和語言有關的元素，例如類別名稱，函式名稱等。 而且，它能針對原始碼的內容進行索引，這意謂一旦建好索引之后，每次搜尋的動作，都毋需重新讀取所有原始碼的內容并逐一搜尋。只需要以現(xiàn)成的索引結構為基礎，即可有效率的尋找關鍵段落。 gtags提供了基于命令列的程式，讓你指定原始碼所在的目錄執(zhí)行建立索引的動作。它同時也提供程式讓你得如同操作grep按一般，針對索引結構進行搜尋及檢索。它提供了許多有用的檢索方式，例如找出專案中定義某個資料結構的檔案及定義所在的行號，或者是找出專案中所有引用某資料結構的檔案，以及引用處的行號。 這么一來，你就可以輕易地針對閱讀程式碼時的需求予以檢索。相較于grep按所能提供的支援， gtags這樣的工具，簡直是強大許多。 再搭配htags制作的HTML文件，更是如虎添翼 還有一個絕對需要一提的工具。這個叫做htags的工具，能夠幫你將已制作完成的索引結構，制作成為一組相互參考的的HTML文件?；旧希眠@樣的的HTML文件閱讀程式碼，比起單純地直接閱讀原始碼，來得更有結構。原因是閱讀程式碼時，這樣的的HTML文件，已經為你建立起在各個原始碼檔案片段間跳躍的鏈結。例如，圖一是針對一個有名的開放原始碼專案ffmpeg ，由gtags所產生出來的的HTML文件首頁的一部分。 htags工具首先為你找出所有定義的Main （ ）函式的檔案，并且列出所在的函式。找出的Main （ ）函式，時常是閱讀程式碼的第一步，因為主要（ ）函式是程式的主要入口點，所有的動作皆由此啟動，它是一切事物的源頭。 憑借htags制作的的HTML文件，你可以輕易地點擊超連結，直接進到的Main （ ）函式所在的程式碼片段，如圖二。 當我們檢視上述原始碼時，發(fā)現(xiàn)av_register_all （ ）是個陌生，無法了解的事物，而想要搞懂它究竟是什么，可以再繼續(xù)點擊這個函式，如圖三。這真是太方便了！閱讀至此，你會猛然發(fā)現(xiàn)， gtags仿佛就是為了閱讀程式碼而專門量身打造的利器。 閱讀他人的程式碼（ 4 ） 望文生義，進而推敲組件的作用先建立系統(tǒng)的架構性認識，然后透過名稱及命名慣例，就可以推測出各組件的作用。例如：當AOL的Winamp嘗試著初始化一個插件時，它會呼叫這個結構中的初始化函式，以便讓每個插件程式有機會初始化自己。當AOL的Winamp打算結束自己或結束某個插件的執(zhí)行時，便會呼叫退出函式。在閱讀程式碼的細節(jié)之前，我們應先試著捕捉系統(tǒng)的運作情境。在采取由上至下的方式時，系統(tǒng)性的架構是最頂端的層次，而系統(tǒng)的運作情境，則是在它之下的另一個層次。好的說明文件難求，拼湊故事的能力很重要有些系統(tǒng)提供良善的說明文件，也許還利用UML的充分描述系統(tǒng)的運作情境。那么對于閱讀者來說，從系統(tǒng)的分析及設計文件著手，便是快速了解系統(tǒng)運作情境的一個途徑。但是，并不是每個軟體專案都伴隨著良好的系統(tǒng)文件，而許多極具價值的開放原始碼專案，也時常不具備此類的文件。對此，閱讀者必須嘗試自行捕捉，并適度地記錄捕捉到的運作情境。我喜歡將系統(tǒng)的運作情境，比擬成系統(tǒng)會上演的故事情節(jié)。在閱讀細節(jié)性質的程式碼前，先知道系統(tǒng)究竟會發(fā)生那些故事，是必備的基本功課。你可以利用熟悉或者自己發(fā)明的表示工具，描述你所找到的情境。甚至可以只利用簡單的列表，直接將它們列出。只要能夠達到記錄的目的，對程式碼閱讀來說，都能夠提供幫助?；蛘?，你也可以利用基于UML中的類別圖，合作圖，循序圖之類的表示方法，做出更詳細的描述。當你能夠列出系統(tǒng)可能會有的情境，表示你對系統(tǒng)所具備的功能，以及在各種情況下的反應，都具備概括性的認識。以此為基礎，便可在任何需要的時候，鉆進細節(jié)處深入了解。探索架構的第一步─ ─找到程式的入口在之前，我們在一個開發(fā)專案中，曾經需要將系統(tǒng)所得到的的MP3音訊檔，放至iPod的這個極受歡迎的播放設備中。雖然iPod的本身也可以做為可移動式的儲存設備，但并不是單純地將MP3播放檔案放到中的iPod ，就可以讓蘋果的播放器認得這個檔案，甚至能夠加以播放。這是因為蘋果利用一個特殊的檔案結構（ iTunes的數(shù)據(jù)庫） ，記錄播放器中可供播放的樂曲，播放清單以及樂曲資訊（例如專輯名稱，樂曲長度，演唱者等） 。為了了解并且試著重復使用既有的程式碼，我們找到了一個AOL的Winamp的iPod的外掛程式（插件） 。AOL的Winamp是個人電腦上極受歡迎的播放軟體，而我們找到的外掛程式，能讓的軟件直接顯示連接至電腦的的iPod中的歌曲資訊，并且允許的軟件直接播放。我們追蹤與閱讀這個外掛程式的思路及步驟如下，首先，我們要先了解外掛程式的系統(tǒng)架構。很明顯的，大概瀏覽過原始碼后，我們注意到它依循著AOL的Winamp為插件程式所制定的規(guī)范，也就是說，它是實作成的Windows上的DLL的，并且透過一個叫做winampGetMediaLibraryPlugin的DLL的函式，提供一個名為winampMediaLibraryPlugin的結構。當我們不清楚系統(tǒng)的架構究竟為何時，我們會試著探索，而第一步，便是找到程式的入口。如何找到呢？這會依程式的性質不同而有所差別。對一個本身就是可獨立執(zhí)行的程式來說，我們會找啟動程式的主要函式，例如對的C / C + +來說就是主要（ ） ，而對爪哇來說，便是靜無效的main （ ） 。在找到入口后，再逐一追蹤，摸索出系統(tǒng)的架構。但有時，我們所欲閱讀的程式碼是類別庫或函式庫，它只是用來提供多個類別或函式供用戶端程式（客戶程序）使用，本身并不具單一入口，此類的程式碼具有多重的入口─ ─每個允許用戶端程式呼叫的函式或類別，都是它可能的入口。例如，對AOL的Winamp的iPod的插件來說，它是一個動態(tài)鏈接庫形式的函式庫，所以當我們想了解它的架構時，必須要先找出它對外提供的函式，而對的Windows的DLL來說，對外提供的函式，皆會以dllexport這個關鍵字來修飾。所以，不論是利用grep按或gtags之類的工具，我們可以很快從原始碼中，找到它只有一個DLL的函式（這對我們而言，真是一個好消息） ，而這個函式便是上述的winampGetMediaLibraryPlugin 。系統(tǒng)多會采用相同的架構處理插件程式如果經驗不夠的話，也許無法直接猜出這個函式的作用。不過，如果你是個有經驗的程式人，多半能從函式所回傳的結構，猜出這個函式實際的用途。而事實上，當你已經知道它是一個插件程式時，就應該要明白，它可能采用的，就是許多系統(tǒng)都采用的相同架構處理插件程式。當一個系統(tǒng)采用所謂插件形式的架構時，它通常不會知道它的插件究竟會怎么實作，實作什么功能。它只會規(guī)范插件程式需要滿足某個特定介面（interface）。當系統(tǒng)初始化時，所有的插件都可以依循相同的方式，向系統(tǒng)注冊，合法宣示自己的存在。雖然系統(tǒng)并不確切知道插件會有什么行為展現(xiàn)，但是因為它制定了一個標準的介面，所以系統(tǒng)仍然可以預期每個插件能夠處理的動作類型。這些動作具體上怎么執(zhí)行，對系統(tǒng)來說并不重要。這也正是物件導向程式設計中的“多型”觀念。隨著實務經驗，歸納常見的架構模式我想表達的重點，是當你“涉世越深”之后，所接觸的架構越多，就越能觸類旁通。只需要瞧上幾眼，就能明白系統(tǒng)所用的架構，自然就能夠直接聯(lián)想到其中可能存在的角色，以及角色間的關系。像上述的插件程式手法，時?？梢栽谠S多允許“外