如何更容易的看懂別人的源代碼--

1、如何看懂源代碼-（分析源代碼方法）我們?cè)趯懗淌綍r(shí)，有不少時(shí)問都是在看別人的 代 碼。例如看小組的代碼，看小組整合的守則，若一開始沒規(guī)劃怎么看，就會(huì)嚕看?？啵ㄅ_(tái)語）”不管是參考也好，從開源抓下來研究也好，為了了 解箇中含意，在有限的時(shí)間下，不免會(huì)對(duì)龐大的源 代碼解讀感到壓力。網(wǎng)路上有一篇關(guān)于分析看代碼的方法，做為程式設(shè) 計(jì)師的您，不妨參考看看，換個(gè)角度來分析。也能更有效率的解讀你想要的 程式碼片段。六個(gè)章節(jié)：（1 ）讀懂程式碼，使心法皆為我所用。（2 ）摸清架構(gòu)，便可輕松掌握全貌。3 ）優(yōu)質(zhì)工具在手，讀懂程式非難事。（4 ）望文生義，進(jìn)而推敲組件的作用。5 ）找到程式入口，再由上而下抽絲剝繭6

2、）閱讀的樂趣，透過程式碼認(rèn)識(shí)作者。閱讀他人的程式碼（ 1 ） - 讀懂程式碼，使心法 皆為我所用程式碼是別人寫的， 只有原作者才真的了解程式碼 的用途及涵義。 許多程式人心里都有一種不自覺的 恐懼感，深怕被迫去碰觸其他人所寫的程式碼。但 是，與其抗拒接收別人的程式碼，不如徹底了解相 關(guān)的語言和慣例，當(dāng)成是培養(yǎng)自我實(shí)力的基石。 對(duì)大多數(shù)的程式人來說， 撰寫程式碼或許是令人開 心的一件事情，但我相信，有更多人視閱讀他人所 寫成的程式碼為畏途。 許多人寧可自己重新寫過一 遍程式碼，也不愿意接收別人的程式碼，進(jìn)而修正 錯(cuò)誤，維護(hù)它們，甚至加強(qiáng)功能。這其中的關(guān)鍵究竟在何處呢？若是一語道破， 其實(shí) 也很簡(jiǎn)

3、單，程式碼是別人寫的，只有原作者才真的 了解程式碼的用途及涵義。 許多程式人心里都有一 種不自覺的恐懼感， 深怕被迫去碰觸其他人所寫的 程式碼。 這是來自于人類內(nèi)心深處對(duì)于陌生事物的原始恐懼 讀懂別人寫的程式碼，讓你收獲滿滿不過，基于許多現(xiàn)實(shí)的原因，程式人時(shí)常受迫要去 接收別人的程式碼。例如，同事離職了，必須接手 他遺留下來的工作，也有可能你是剛進(jìn)部門的菜 鳥，而同事經(jīng)驗(yàn)值夠了，升級(jí)了，風(fēng)水輪流轉(zhuǎn)，一 代菜鳥換菜鳥。甚至，你的公司所承接的專案，必 須接手或是整合客戶前一個(gè)廠商所遺留下來的系 統(tǒng)，你們手上只有那套系統(tǒng)的原始碼（運(yùn)氣好時(shí)， 還有數(shù)量不等的文件）。諸如此類的故事，其實(shí)時(shí)常在程式人身邊

4、或身上持 續(xù)上演著。許多程式人都將接手他人的程式碼，當(dāng) 做一件悲慘的事情。每個(gè)人都不想接手別人所撰寫 的程式碼，因?yàn)椴幌牖〞r(shí)間去探索，寧可將生產(chǎn)力 花在產(chǎn)生新的程式碼，而不是耗費(fèi)在了解這些程式 碼上。很遺憾的是，上述的情況對(duì)程式人來說很難避免。 我們總是必須碰觸到其他人所寫成的程式碼，甚至必須了解它，加以修改。對(duì)于這項(xiàng)需求，在現(xiàn)今開放原始碼的風(fēng)氣如此盛行的今日，正如之前的“程式 設(shè)計(jì) 2.0 ”文中所提到的，你可以透過開放原始碼 學(xué)習(xí)到新的技術(shù)，學(xué)習(xí)到高手的架構(gòu)設(shè)計(jì)，大幅提 高學(xué)習(xí)的效率及效果。你甚至可以直接自開放原始 碼專案中抽取，提煉出自己所需的程式碼，站在巨 人的肩膀上，直接由彼端獲得所

5、需的生產(chǎn)力。從這 個(gè)觀點(diǎn)來看，讀懂別人所寫的程式碼，就不再只是 從負(fù)面觀點(diǎn)的“被迫接收”，而是極具正面價(jià)值的 “汲取養(yǎng)份。 ”先了解系統(tǒng)架構(gòu)與行為模式，再細(xì)讀 倘若撰寫程式碼是程式人的重要技藝之一， 那么讀 懂別人的程式碼，接著加以修改，也勢(shì)必是另一個(gè) 重要的技藝。如果你不能熟悉這項(xiàng)工作，不僅在遭逢你所不愿面 對(duì)的局面時(shí)，無法解決眼前接手他人程式碼的難 題，更重要的是，當(dāng)你看著眼前現(xiàn)成的程式碼，卻 不知如何從中擷取自己所需， 導(dǎo)致最后只能入寶山 空手回，望之興嘆。接觸他人的程式碼，大致上可以分為三種程度：了解，二，修改，擴(kuò)充，三，抽取，提煉。了解別 人的程式碼是最基礎(chǔ)的工作， 倘若不能了解自己

6、要 處理的程式碼，就甭論修改或擴(kuò)充，更不可能去蕪 存菁，從中萃取出自己所需，回收再利用別人所撰 寫的程式碼。雖說是閱讀”，但程式碼并不像文章 或小說一樣，透過這種做法，便能夠獲得一定程度 的了解。閱讀文章或小說時(shí)，幾乎都是循序地閱讀， 你只消翻開第一頁，一行行閱讀下去即可。但是， 有許多程式人在試著閱讀其他人的程式碼時(shí)，卻往往有不知如何讀起的困難?；蛟S找到系統(tǒng)的第一頁（也就是程式碼執(zhí)行的啟始 點(diǎn)）并不難，但是復(fù)雜度高的系統(tǒng)，有時(shí)十分龐大， 有時(shí)千頭萬緒。從程式碼的啟始點(diǎn)開始讀起，一來要循序讀完所有 的程式碼曠日費(fèi)時(shí)，二來透過這種方式來了解系 統(tǒng)，很難在腦中構(gòu)建出系統(tǒng)的面貌，進(jìn)而了解到系 統(tǒng)真正

7、的行為。所以，閱讀程式碼的重點(diǎn)，不在于 讀完每一行程式碼，而是在于有效率地透過探索及 閱讀，從而了解系統(tǒng)的架構(gòu)及行為模式。以便在你 需要了解任何片段的細(xì)節(jié)實(shí)作時(shí)，能夠很快在腦上 對(duì)映到具體的程式碼位置，直到那一刻，才是細(xì)讀 的時(shí)機(jī)。熟悉溝通語言與慣例用語不論如何，有些基本的準(zhǔn)備，是閱讀他人程式碼時(shí) 必須要有的。首先，你最好得了解程式碼寫成的程式語言。想要 讀懂法文寫成的小說，總不能連法文都不懂吧。有 些情況則很特殊。我們雖然不懂該程式碼撰寫所用 的語言，但是因?yàn)楝F(xiàn)代語言的高階化，而且流行的 程式語言多半都是血統(tǒng)相近，所以即使不那么熟 悉，有時(shí)也可勉力為之。除了認(rèn)識(shí)所用語言之外，再來就是要先確認(rèn)

8、程式碼 所用的命名慣例（命名慣例） 。了解命名慣例很 重要，不同的程式人或開發(fā)團(tuán)隊(duì)，差異可能很大。這命名慣例涵蓋的范圍通常包括了變數(shù)的名稱，函式的名稱，類別（如果是物件導(dǎo)向的話）的名稱， 原始碼檔案，甚至是專案建構(gòu)目錄的名稱。倘若使 用了像設(shè)計(jì)模式之類的方法， 這些名稱更有一些具體的表述方式命名慣例有點(diǎn)像是程式人在程式語言之上，另行建構(gòu)的一組溝通行話。程式人會(huì)透過共通約束，遵守 的命名慣例，來表達(dá)一些較高階的概念。例如，有 名的匈牙利式命名法，便將變數(shù)名稱以屬性，型別, 說明合并在一起描述。對(duì)程式人來說，這種方式能 夠提供更豐富的資訊，以了解該變數(shù)的作用及性 質(zhì)。對(duì)程式碼閱讀來說，熟悉這個(gè)做法

9、之所以重要，是 因?yàn)楫?dāng)你了解整個(gè)系統(tǒng)所采用的慣例時(shí)， 你便能試 著以他們所共同操用的語匯來進(jìn)行理解。倘若，不 能了解其所用的慣例，那么這些額外提供的資訊， 就無法為你所用。像以設(shè)計(jì)模式寫成的程式碼，同 樣處處充滿著模式的名稱，諸如：工廠，門面，代 理等等。以這些名稱指涉的類別，也直接透過名稱， 表達(dá)了它們自身的作用。對(duì)于懂得這命名慣例的讀 者來說，不需要深入探索，也能很快捕捉到這些類 別的意義。當(dāng)你拿到一套必須閱讀的程式碼時(shí)，最好先取得命 名慣例的說明文件。然而，并不是每套程式碼都附 有此類的說明文件。另一個(gè)方式，就是自己到程式 碼中，大略瀏覽一遍，有經(jīng)驗(yàn)的程式人可以輕易發(fā) 掘出該系統(tǒng)所用的命

10、名慣例。常見的命名方式不脫那幾類，這時(shí)候經(jīng)驗(yàn)就很重 要，倘若你知道的慣例越多，就越能輕易識(shí)別他人 所用的慣例。如果運(yùn)氣很糟，程式碼所用的慣例是 前所未見的，那么你也得花點(diǎn)時(shí)間歸納，憑自己的 力量找出這程式碼命名上的規(guī)則。掌握程式碼撰寫者的心態(tài)與習(xí)慣大多數(shù)的程式碼，基本上都依循一致的命名慣例。 不過運(yùn)氣更差的時(shí)候，一套系統(tǒng)中可能會(huì)充斥著多 套命名慣例。這有可能是因?yàn)殚_發(fā)團(tuán)隊(duì)由多組人馬 所構(gòu)成，每組人馬都有不同的文化，而在專案開發(fā) 管理又沒有管控得宜所造成。最糟的情況，程式碼 完全沒有明顯的慣例可言，這時(shí)候閱讀的難度就更想要閱讀程式碼，得先試著體會(huì)程式碼作者的心O想要這么做，就得多了解對(duì)方所使用的

11、語言，以及慣常運(yùn)用的語匯。在下一回中，我們將繼續(xù)探 討閱讀程式碼的相關(guān)議題。閱讀他人的程式碼（ 2 ） -摸清架構(gòu)，便可輕松 掌握全貌在本文中，我們的重點(diǎn)放在：要了解一個(gè)系統(tǒng)，最 好是采取由上至下的方式。先試著捕捉系統(tǒng)架構(gòu)性 的觀念，不要過早鉆進(jìn)細(xì)節(jié)，因?yàn)槟峭ǔ?duì)于你了 解全貌，沒有多大的幫助。閱讀程式碼不需要從第 一行讀起，我們的目的并不是在于讀遍每一段程式 碼?；谠S多原因，程式人需要閱讀其他人所寫成的程 式碼。而對(duì)程式設(shè)計(jì) 2.0 時(shí)代的程式人來說，最正 面的價(jià)值在于，能讀懂別人程式的人，才有能力從 中萃取自己所需的程式，借以提高生產(chǎn)力。閱讀程式碼的目的，在于了解全貌而非細(xì)節(jié) 想要讀懂別

12、人程式碼的根本基礎(chǔ)， 便是了解對(duì)方所 用的程式語言及命名慣例。有了這個(gè)基礎(chǔ)之后，才 算是具備了基本的閱讀能力。正如我之前提到的一 想要讀懂法文寫成的小說，總不能連法文都不懂 吧。閱讀程式碼和閱讀文學(xué)作品，都需要了解撰寫所用的語言及作者習(xí)用的語匯但我們?cè)陂喿x文學(xué)作品通常是采循序的方式，也就是從第一頁開始，一行一行地讀下去，依循作者為 你鋪陳的步調(diào)，逐漸進(jìn)到他為你準(zhǔn)備好的世界里。 閱讀程式碼卻大大不同。我們很少?gòu)牡谝恍虚_始讀 起，因?yàn)槌撬呛芎?jiǎn)單的單執(zhí)行緒程式，否則很 少這么做。因?yàn)橐沁@么做，就很難了解整個(gè)系統(tǒng) 的全貌。是的，我們這邊提到了一個(gè)重點(diǎn)，閱讀程 式碼的目的在于了解系統(tǒng)的全貌， 而不

13、是在于只是 為了地毯式的讀遍每一段程式碼。就拿物件導(dǎo)向程式語言所寫成的系統(tǒng)來說，整個(gè)系統(tǒng)被拆解，分析成為一個(gè)個(gè)獨(dú)立的類別。閱讀個(gè)別 類別的程式碼，或許可以明白每項(xiàng)類別物件個(gè)別的 行為。但對(duì)于各類別物件之間如何交互影響，如何 協(xié)同工作，又很容易陷入盲人摸象的困境。這是因 為各類別的程式碼，只描述個(gè)別物件的行為，而片 段的閱讀就只能造就片面的認(rèn)識(shí)。由上而下厘清架構(gòu)后，便可輕易理解組成關(guān)系 如果你想要跳脫困境，不想浪費(fèi)大量時(shí)間閱讀程式 碼，卻始終只能捕捉到對(duì)系統(tǒng)片段認(rèn)識(shí)，就必須轉(zhuǎn) 換到另一種觀點(diǎn)來看待系統(tǒng)。 從個(gè)別的類別行為著 手，是由下至上 （自下而上） 的方法 ;在閱讀程式碼 時(shí)，卻應(yīng)該先采由上

14、至下（自上而下）的方式。對(duì) 程式碼的閱讀來說，由上至下意謂著，你得先了解 整個(gè)系統(tǒng)架構(gòu)。系統(tǒng)的架構(gòu)是整個(gè)系統(tǒng)的骨干，支柱。它表現(xiàn)出系 統(tǒng)最突出的特征。 知道系統(tǒng)架構(gòu)究竟屬于那一種類 型，通常大大有益于了解系統(tǒng)的個(gè)別組成之間的靜 態(tài)及動(dòng)態(tài)關(guān)系。 有些系統(tǒng)因?yàn)樗玫募夹g(shù)或框架的 關(guān)系，決定了最上層的架構(gòu)。例如，采用的 Java Servlet 的 / JSP 的技術(shù)的應(yīng)用系統(tǒng)， 最外層的架構(gòu) 便是以 J2EE 的（或起碼的 J2EE 中的 Web 容器） 為根本。使用的 Java Servlet 的/ JSP 的技術(shù)時(shí)， 決定了某 些組成之間的關(guān)系。例如， Web 容器依據(jù) web.x ml 中的

15、內(nèi)容載入所有的 Servlets ，聽眾，以及過 濾器。每當(dāng)語境發(fā)生事件（例如初始化）時(shí)，它便 會(huì)通知監(jiān)聽類別。每當(dāng)它收到來自客戶端的請(qǐng)求 時(shí)，便會(huì)依循設(shè)定的所有過濾器鏈，讓每個(gè)過濾器 都有機(jī)會(huì)檢查并處理此一請(qǐng)求， 最后再將請(qǐng)求導(dǎo)至 用來處理該請(qǐng)求的 Servlet 的。當(dāng)我們明白某個(gè)系統(tǒng)采用這樣的架構(gòu)時(shí)， 便可以很 容易地知道各個(gè)組成之間的關(guān)系。 即使我們還不知 道究竟有多少 Servlets ，但我們會(huì)知道，每當(dāng)收 到一個(gè)請(qǐng)求時(shí)， 總是會(huì)有個(gè)相對(duì)應(yīng)的服務(wù)器來處理 它。當(dāng)想要關(guān)注某個(gè)請(qǐng)求如何處理時(shí)，我應(yīng)該去找 出這個(gè)請(qǐng)求對(duì)應(yīng)的服務(wù)器。了解架構(gòu)，必須要加上層次感 同樣的，以爪哇寫成的網(wǎng)頁應(yīng)用程

16、式中，也許會(huì)應(yīng) 用諸如 Struts 的之類的的 MVC 框架，以及像 Hib ernate 的這樣的資料存取框架。 它們都可以視為最 主要的架構(gòu)下的較次級(jí)架構(gòu)。而各個(gè)應(yīng)用系統(tǒng)，甚 至有可能在 Struts 的及休眠之下， 建立自有的更次 級(jí)的架構(gòu)。也就是說，當(dāng)我們談到 “架構(gòu) ”這樣的觀念時(shí)，必須 要有層次感。而不論是那一層級(jí)的架構(gòu)，都會(huì)定義 出各自的角色， 以及角色間的關(guān)系。 對(duì)閱讀者來說， 相較于直接切入最細(xì)微的單一角色行為， 不如了解 某個(gè)特定的架構(gòu)中，究竟存在多少角色，以及這些 角色之間的互動(dòng)模式， 比較能夠幫助我們了解整個(gè) 系統(tǒng)的運(yùn)作方式。這是一個(gè)很重要的關(guān)鍵， 當(dāng)你試著進(jìn)到最細(xì)節(jié)

17、處之 前，應(yīng)該先試著找出參與的角色，及他們之間的關(guān) 系。例如，對(duì)事件驅(qū)動(dòng)式的架構(gòu)而言，有 3 個(gè)很重 要的角色。一個(gè)是事件處理的分派器（事件調(diào)度），一個(gè)是事件產(chǎn)生者（事件發(fā)生器） ，另一個(gè)則 是事件處理器（事件處理程序） 。事件產(chǎn)生器產(chǎn)生事件，并送至事件分派器，而事件 分派器負(fù)責(zé)找出各事件相對(duì)應(yīng)的事件處理器， 并且 轉(zhuǎn)交該事件，并命令事件處理器加以處理。像的圖 形用戶界面的 Windows 應(yīng)用程式，便是采用事件 驅(qū)動(dòng)式的架構(gòu)。當(dāng)你知道此類的應(yīng)用程式皆為事件驅(qū)動(dòng)式的架構(gòu) 時(shí)，你便可以進(jìn)一步得知，在這樣的架構(gòu)下會(huì)有 3 種主要的角色。雖然也許還不清楚整個(gè)系統(tǒng)中，究 竟會(huì)需要處理多少事件的類型，但

18、對(duì)你而言，已經(jīng) 建立了對(duì)系統(tǒng)全貌最概觀的認(rèn)識(shí)。雖然你還不清楚所有的細(xì)節(jié)， 但諸如確切會(huì)有那些 事件類型之類的資訊，在此刻還不重要要忘 了，我們采取的是由上而下的方式，要先摸清楚主 建筑結(jié)構(gòu)，至于壁紙的花色怎么處理，那是到了尾 聲時(shí)才會(huì)做的事。探索架構(gòu)的第一件事：找出系統(tǒng)如何初始化 有經(jīng)驗(yàn)的程式人，對(duì)于時(shí)常被運(yùn)用的架構(gòu)都很熟 悉。常常只需要瞧上幾眼，就能明白一個(gè)系統(tǒng)所用 的架構(gòu)，自然就能夠直接聯(lián)想到其中會(huì)存在的角 色，以及角色間的關(guān)系。然而，并不是每個(gè)系統(tǒng)所 用的架構(gòu)，都是大眾所熟悉，或是一眼能夠望穿的。 這時(shí)候，你需要探索。目標(biāo)同樣要放在界定其中的 角色，以及角色間的靜態(tài)，動(dòng)態(tài)關(guān)系。不論某個(gè)系

19、統(tǒng)所采用的架構(gòu)是否為大部分人所熟 知的，在試著探索一個(gè)系統(tǒng)的長(zhǎng)相時(shí)，我們應(yīng)該找 出來幾個(gè)答案，了解在它所用的架構(gòu)下，下列這件 事是如何被完成的：一，系統(tǒng)如何初始化，二，與 這個(gè)系統(tǒng)相接的其他系統(tǒng)（或使用者）有那些，而 相接的介面又是什么 ;三，系統(tǒng)如何反應(yīng)各種事件，四，系統(tǒng)如何處理各種異常及錯(cuò)誤。系統(tǒng)如何初始化是很重要的一件事，因?yàn)槌跏蓟?為了接下來的所有事物而做的準(zhǔn)備。 從初始化的方 式，內(nèi)容，能知道系統(tǒng)做了什么準(zhǔn)備，對(duì)于系統(tǒng)會(huì) 有什么行為展現(xiàn)，也就能得窺一二了。之所以要了 解與系統(tǒng)相接的其他系統(tǒng)（或使用者），為的是要界定出系統(tǒng)的邊界。其他的系統(tǒng)可能會(huì)提供輸入 給我們所探索的系統(tǒng)，也可能接

20、收來自這系統(tǒng)的輸 出，了解這邊界所在，才能確定系統(tǒng)的外觀。而系統(tǒng)所反應(yīng)的事件類型，以及如何反應(yīng)，基本上 就代表著系統(tǒng)本身的主要行為模式。最后，我們必 須了解系統(tǒng)處理異常及錯(cuò)誤的方式，這同樣也是系 統(tǒng)的重要行為，但容易被忽略。之前，我們提到必 須先具備一個(gè)系統(tǒng)的語言基礎(chǔ)， 才能夠進(jìn)一步加以 閱讀，而在本文中，我們的重點(diǎn)放在：要了解一個(gè) 系統(tǒng)，最好是采取由上至下的方式。先試著捕捉系 統(tǒng)架構(gòu)性的觀念，不要過早鉆進(jìn)細(xì)節(jié)，因?yàn)槟峭ǔ?對(duì)于你了解全貌，沒有多大的幫助。閱讀他人的程式碼（ 3 ） -優(yōu)質(zhì)工具在手，讀懂 程式非難事系統(tǒng)的復(fù)雜度往往超過人腦的負(fù)荷。 閱讀程式碼的 時(shí)候，你會(huì)需要更多工具提供協(xié)助。

21、使用好的整合 式開發(fā)環(huán)境（ IDE ）的或文字編輯器，就能提供 最基本的幫助。閱讀程式碼的動(dòng)作，可以是很原始的，利用最簡(jiǎn)單 的文字編輯器，逐一開啟原始碼，然后憑借著一己 的組織能力，在不同的程式碼間跳躍，拼湊出腦中 想要構(gòu)建的圖像。不過，系統(tǒng)的復(fù)雜度往往超過人腦的負(fù)荷。閱讀程 式碼的時(shí)候，你會(huì)需要更多工具提供協(xié)助。使用好 的整合式開發(fā)環(huán)境（ IDE ）的或文字編輯器，就 能提供最基本的幫助。善用文字編輯器或 IDE 中，加速解讀程式碼 許多文字編輯器提供了常見程式語言的語法及關(guān) 鍵字標(biāo)示功能。這對(duì)于閱讀來說，絕對(duì)能夠起很大 的作用。有些文字編輯器（例如我常用的編輯器及 偶而使用的記事本 + +

22、 ） ，甚至能夠自動(dòng)列出某 個(gè)原始檔中所有定義的函式清單， 更允許你直接從 清單中選擇函式，直接跳躍到該函式的定義位置。 這對(duì)于閱讀程式碼的人來說， 就提供了極佳的便利 性。因?yàn)樵陂喿x程式碼時(shí)，最常做的事，就是隨著程式 中的某個(gè)控制流，將閱讀的重心，從某個(gè)函式移至 它所呼叫的另一個(gè)函式。所以對(duì)程式人來說，閱讀 程式碼時(shí)最常做的事之一就是： 找出某個(gè)函式位在 那一個(gè)原始檔里，接著找到該函式所在的位置。好的的 IDE 能夠提供的協(xié)助就更多了。 有些能夠自 動(dòng)呈現(xiàn)一些額外的資訊， 最有用的莫過于函式的原 型宣告了。 例如， 有些的 IDE 支援當(dāng)游標(biāo)停留在某 函式名稱上一段時(shí)間后， 它會(huì)以提示的方式

23、顯示該 函式的原型宣告。對(duì)閱讀程式碼的人來說， 在看到程式碼中呼叫到某 個(gè)函式時(shí)，可以直接利用這樣的支援，立即取得和 這個(gè)函式有關(guān)的原型資訊， 馬上就能知道呼叫該函 式所傳入的各個(gè)引數(shù)的意義， 而不必等到將該函式 的定義位置找出后，才能明白這件事。grep 按（讀者：推薦來源透視）是一個(gè)基本而極 為有用的工具除了選用好的文字編輯器或的 IDE 之外，還有一個(gè) 基本，但卻極為有用的工具，它就是 grep 按。熟 悉的 Unix 作業(yè)系統(tǒng)的程式人， 對(duì) grep 按這個(gè)公用 程式多半都不陌生。 grep 按最大的用途，在于它 允許我們搜尋某個(gè)目錄（包括遞回進(jìn)入所有子目 錄）中所有指定檔案，是否有符

24、合指定條件（常數(shù) 字串或正規(guī)表示式）檔案。倘若有的話，則能幫你指出所在的位置。這在閱讀 程式碼時(shí)的作用極大。當(dāng)我們隨著閱讀的腳步，遇 上了任何一個(gè)不認(rèn)識(shí)， 但自認(rèn)為重要的類別， 函式， 資料結(jié)構(gòu)定義或變數(shù)， 我們就得找出它究竟位在這 茫茫程式碼海中的何處， 才能將這個(gè)圖塊從未知變 為已知。grep 按之所以好用， 就是在于當(dāng)我們發(fā)現(xiàn)某個(gè)未知 的事物時(shí)， 可以輕易地利用它找出這個(gè)未知的事物 究竟位在何方。此外，雖說 grep 按是 Unix 系統(tǒng)的 標(biāo)準(zhǔn)公用程式之一，但是像視窗這樣子的平臺(tái)，也 有各種類型的 grep 按程式。對(duì)于在視窗環(huán)境工作的程式人來說，可以自行選用覺得稱手的工具gtags

25、可建立索引，讓搜尋更有效率 grep 按雖然好用， 但是仍然有一些不足之處。 第一 個(gè)缺點(diǎn)在于它并不會(huì)為所搜尋的原始碼檔案索引。 每當(dāng)你搜尋時(shí)，它都會(huì)逐一地找出所有的檔案，并 且讀取其中的所有內(nèi)容， 過濾出滿足指定條件的檔 案。當(dāng)專案的原始碼數(shù)量太大時(shí)，就會(huì)產(chǎn)生搜尋效 率不高的問題。第二個(gè)缺點(diǎn)是它只是一個(gè)單純的文字檔搜尋工具， 本身并不會(huì)剖析原始碼所對(duì)應(yīng)的語言語法。 當(dāng)我們 只想針對(duì) “函式 ”名稱進(jìn)行搜尋時(shí)，它有可能將注解 中含有該名稱的原始碼，也一并找了出來。針對(duì) grep 按的缺點(diǎn)，打算閱讀他人程式碼的程式 人，可以考慮使用像是 gtags 這樣子的工具。 gta gs 是源代碼的 GN

26、U 全局標(biāo)記系統(tǒng)， 它不只搜尋文 字層次，而且因?yàn)榫邆淞烁鞣N語言的語法剖析器， 所以在搜尋時(shí)，可以只針對(duì)和語言有關(guān)的元素，例 如類別名稱，函式名稱等。而且，它能針對(duì)原始碼的內(nèi)容進(jìn)行索引，這意謂一 旦建好索引之后，每次搜尋的動(dòng)作，都毋需重新讀 取所有原始碼的內(nèi)容并逐一搜尋。 只需要以現(xiàn)成的 索引結(jié)構(gòu)為基礎(chǔ)，即可有效率的尋找關(guān)鍵段落。gtags 提供了基于命令列的程式，讓你指定原始碼 所在的目錄執(zhí)行建立索引的動(dòng)作。 它同時(shí)也提供程 式讓你得如同操作 grep 按一般，針對(duì)索引結(jié)構(gòu)進(jìn) 行搜尋及檢索。它提供了許多有用的檢索方式，例 如找出專案中定義某個(gè)資料結(jié)構(gòu)的檔案及定義所 在的行號(hào)， 或者是找出專案中所有引用某資料結(jié)構(gòu) 的檔案，以及引用處的行號(hào)。這么一來， 你就可以輕易地針對(duì)閱讀程式碼時(shí)的需 求予以