瀏覽大型代碼庫的提示和技巧

前言

我相信現在大學中所進行的計算機科學（CS）教育缺乏對學生關於如何在非常大的代碼庫中查找信息（navigate）以及如何快速地理解代碼庫的指導。

可能大多數計算機專業（CS）的學生最後會到中小型的企業工作，在這樣的企業中，他們往往只需要關注某一個規模不大的程序或代碼庫。對於這樣的代碼庫，公司的老員工將非常熟悉，所以能夠在較高的層面上（at a high level）為新人對其中的每個部分都解釋清楚。

另一個可能的原因（很可能是更準確的，但是大學教授們不會承認的一個原因）是老師們自己都從來沒有處理過超過十萬行的代碼庫，更是很少處理別人寫的代碼（除了他們自己的學生寫的），但這是另外一篇文章討論的內容。

回到主題上來，我認為當我們加入了像微軟、亞馬遜、谷歌、Facebook或者任何那些為數不多的可以真正被稱作「大型技術公司」的企業中時，很容易就陷入迷茫（get lost）並缺乏生產力（fail to be productive）。

從我以前指導過的實習生的實際情況來看，似乎沒有人教過他們當代碼像消防管出來的水一樣向他們湧來時該如何應對。所以我這裡出一份力，希望能夠幫助到未來的程序員們。

在代碼中迷失

在許多情況下，你可能會發現自己必須瀏覽一個大的外部代碼庫。其中一些例子如下：

你團隊中最資深的人員可能僅待了不到一年，特別是在一個流失率很高的公司，他們自己可能不知道團隊要維護的大部分系統，因為他們目前還不需要處理該系統。現在，一個新功能需要添加到遺留系統中，猜猜老闆選擇怎麼做？

你正在處理另一個團隊的代碼，他們沒有時間（或不想）向你解釋，但你又想/需要了解該代碼。

你正在從事一些跨部門的工作，例如性能或效率，這要求你不斷在其他人的代碼中工作，並以每周（或每天）為基礎進行對比。

與長時間使用相同的代碼相比，這通常會使你處於劣勢。

那麼，在不浪費大量時間的前提下，如何才能簡單地地找到相關的代碼和編寫（理解）這個相同的代碼呢？

下面會告訴你。

1. 不要慌

每個擁有優良品行的倖存者都會告訴你：野外生存的第一條規則是「不要慌張」。

那麼如果在上午2點，伺服器正在處於崩庫邊緣，你的錢像血一樣流失，所有的高級工程師都在 Tahoe 進行一年一度的公司旅行中，你被迫忙於技術支持，你該怎麼做呢？

現在不是聽之任之，並希冀你已經輟學，在和懷俄明州的嬉皮姐妹一起養山羊的時候。 該死的山羊！ 這裡有很多待讀的代碼。

2. 將相關代碼放到眼前

你需要擅長的第一件事是快速找到正確的代碼段，並將其放在你的眼球前。這可能聽起來很愚蠢，但是我已經浪費了很多時間（有時會更多）閱讀那些我不感興趣的代碼片段。

在花費大量時間閱讀部分大型程序之前，需要做兩件事情：首先要找到相關的代碼，然後在深入閱讀前再次確定這就是正確代碼段。

在代碼中識別和檢索（grep）奇怪的短語

想要弄清楚哪些代碼引起了一些行為的發生或者某些UI元素的出現，一個最簡單確實最強大的方法，就是檢索（grep for，指的應該是使用類似 grep 的行搜索工具進行搜索）你能找到的一些奇怪的詞句（odd phrases）。

如果你不知道如何在一個代碼庫中檢索信息，我建議你去查一下資料。如果你用的是git，那麼這裡有一篇很好的文章可以給你這方面的指引。如果你不會正則表達式，那你一定要學會它。因為使用正則表達式是一個非常有用的技能，而且網上有大量很好的教程。我好像離題了...

如果一個 web 頁面上出現了這樣一句話「All events are logged in the Pacific (PST) timezone.」，我認為那是一條很有價值的線索。你想一下，在一個有兩百萬行代碼的庫中這樣一個帶著特定大小寫字元的長句會出現多少次？可能有那麼幾次，但是至少可以把我們的目標鎖定在為數不多的幾個文件中。接下來我們再根據找到的文件的文件名來進一步過濾掉明顯無關的代碼。

「CatShouldBeADogException thrown」之類的信息是另外一個很有價值的線索。 自定義的異常(custom exception)（特別是在Java中）通常只會在4到5個地方被用到。 再結合一些你正在處理的環境中的信息, 例如 stack trace 中的其他內容，或者在這之前的兩條告訴你程序進入了某個方法的日誌記錄， 你可以很快地縮小範圍並找到那幾行相關的代碼。

日誌行消息是查找代碼的另一個好方法。「Starting to process log lines with x lines」 是一個不太可取的短語搜索。 首先，x是動態的，意思是你真正應該 grep 的是 「Starting to process log lines」。 因為語句可能包含引號和列印語句，所以更多的 grep 將是無意義的。

通常這些方法是一個好的開始。但是如果這都不能讓你找到你想要的信息呢？

責任追蹤

你知道誰在開發某個特性，但你知道他們正在編寫哪部分代碼嗎？很簡單，只需要對他們進行責任追蹤即可！

不過什麼是責任追蹤？

任何時候某人提交了一段代碼到某個源代碼版本控制庫(git、mercurial、svn 等)，他們的名字或登錄名都會與這次提交關聯起來。

如果你知道某人正在處理某個特定的功能，那麼查找相關的代碼就非常簡單，就像在庫中尋找他們接觸過的文件一樣簡單！

如果你對別人正在做什麼感到好奇，或者，你認為他們就是奇才，想看看大師級的示例(嘿，這是學習的好方法)，那麼這個方法很適合你。

具體步驟取決於源碼版本控制工具，舉例來說，如果你想看到我提交的所有東西(包括修改的文件)，Git 中可以使用git log —name-only —author=imperio59。

從「代碼入口」開始

有時候，並沒有什麼好的方式可以知道從哪裡開始看起。你已經嘗試過全文搜索定位一些生僻的詞語，你也嘗試過單步調試跟蹤代碼。現在你無計可施了。現在也許是時候重整旗鼓、從最開頭的代碼開始了。

尋找當前程序代碼的入口點（從多種方面來看，這都是具有指導性意義的），順著代碼的走向前進。不過，這種方法可能是相當耗時的，所以請把它當成最後一招。

找到要修改的代碼並確認是那些代碼

在你花費數分鐘或數小時閱讀這10,000行的義大利粉和肉丸類代碼之前，你應該確認這是不是一個好想法。

添加一行列印語句，運行代碼並確認你的列印語句輸出吧。最佳的語句是 echo(「」)。程序直接列印出你的姓的可能性不高，需要在日誌或者輸出中過濾，這樣將會簡單些。

你應該一遍又一遍（複製/粘貼）地重複一些像「FOOFOOFOOFOOFOOFOOFOOFOO」這樣的短語。這是我朋友用來調試列印最愛的語句，這樣的輸出在日誌中很顯眼（這不包括他幼稚地喜歡用 P 代替 F 哦！你知道的，他總是喜歡開一些玩笑！）

3. 閱讀部分代碼

好了，你找到了你想閱讀的相關代碼了。那麼接下來怎麼辦呢？

閱讀的時間到了！但不只是隨便看看，不行的。我們要閱讀，所以我們可以知道我們正在閱讀什麼。這是有差別的看。愚蠢地逐行掃描對我們沒有任何好處，不是為了對我們待讀的代碼一知半解，希望我們能夠獲得一些神奇的理解，或者通過深入、重複的閱讀，我們將會「get it」。

在我看來，有三個主要的東西可以阻礙你對別人的代碼的理解：

你不明白代碼編寫的一些規約。 （命名約定，樣式約定...）

你不明白特定函數究竟做了什麼，因為你從來沒有遇到過。

你不明白編程語言本身的一些功能。

我們來看看如何處理這些問題：

1.編碼約定，風格指南以及人們自己發明的東西

在對變數、類或方法命名時，人們並不會使用那麼多的約定。有賴於你所使用的語言，一些命名約定可能就是語言本身的一部分（變數或函數應該以此樣式命名，因為它就得是這樣）。

對於命名約定，我發現人們通常會堅持基礎的常識。歷久彌新的匈牙利命名法或者是其一小部分現如今仍然在被廣泛地運用著。有時候，人們會向類的每一個成員變數名字前頭添加一個小寫字母m，以此區別於局部變數。有些人就乾脆規定成員變數要使用首字母小寫的駝峰命名法來寫，而本地變數則全部小寫（memberVariablesInCamelCase ），並且單詞之間用下劃線分割（local_variables_have_underscores）。有時私有函數名以下劃線開頭（_startWithAnUnderscore），而公共方法則並不這樣做（publicMethodsDont），同樣是以示區分。

不管約定是如何定義的，都得是清晰並且能快速進行識別的。如果幸運的話，內部知識庫裡面會有一個公開發行的代碼風格指南，這樣大家就省事兒了。關鍵是你得去閱讀它。回頭讀過代碼之後再來讀一下風格指南。

代碼約定不是魔鬼，它們通過幫助你快速地對變數和函數的類型進行歸類，來幫助你加快閱讀和理解代碼的加速。不過只有在你對約定相當熟悉的前提下，他們才會有加快速度的效果，不這樣的話，它們就會在你每次遇到它時通過增加一些額外的溝溝坎坎來彌補你對此的理解。 （「為什麼他們現在命名為 mServiceManager 而不是 serviceManager 呢？」）。

最後就是，有時人們會發明自己的風格指南，但並不會在任何地方發表。如果照我的經歷來說，要麼就是編寫代碼的人是當時比較匆忙，回頭沒有寫一個風格指南，或者留下任何的記錄文件（以防留下了什麼蛋疼的BUG到時候沒法追溯源頭），要麼就是這個人太自我——這種人經常對寫一個風格指南或者說明一下他們在做什麼表示不屑（諸如「我的代碼不需要單元測試，因為它沒有錯誤」此類的，對吧！），在這樣的情況下，代碼會被過度設計，封裝得跟一個鉛球似的，而且BUG重重。

無論採用哪種方式，使用一些非標準的，不成文的編碼約定就是一個很可能會有問題發生的跡象，這時候就當心點吧。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！