這8點能教你如何更好地閱讀代碼

譯者：Tocy, 亞林瓜子, 總長

來源：開源中國

鏈接：https://www.oschina.net/translate/how-to-read-code

我討厭閱讀別人的代碼」是所有經驗層級上的軟體開發人員之間普遍存在的問題。然而，這又是一個必要的技能，特別是對於開發人員進入到現有的代碼庫中的時候，如果你以正確的角度和正確的工具來處理它，這可能是一個愉快和有啟發性的體驗。

我們討厭閱讀別人的代碼的原因是因為代碼不是我們自己寫的。這不是因為我們認為自己是地球上最好的編碼人員，沒有人可以像我們這樣編寫好的代碼。而是因為在創建代碼時有一個積極的思維過程，而被動的閱讀者並沒有獲得這種親身體驗的益處。

你在屏幕上看到的代碼可能涉及多個人。它可能涉及辯論和協作。它可能需要幾個星期才能完成符合只在原作家頭腦中的一些未文檔化的限制的版本——但是你對此卻不可得知。

作為讀者，你看到的所有產品都是成品，除非你做一點挖掘，否則你唯一得到的就是屏幕上的其他單詞。

-1-

學會深挖

當你第一次深入成熟的代碼庫時，你可能感覺自己不像開發人員。你可能更像是考古學家、私人調查員或聖經學者。這很好，因為你有一大堆事情需要處理。

如果你有幸能夠從一開始就接觸使用版本控制的代碼庫，那麼就該慶祝一下。你可以訪問豐富的元數據，這將使你理解的不僅僅是代碼，還包括上下文，都會容易很多。我會假設你使用 Git ，但是如果你使用 SVN ，那麼這個想法也是同樣適用的。

你可以在文件上使用 git blame 來獲取每一行的提交名、上次修改日期和提交哈希值。熟悉這些提交者。如果你足夠幸運的話，可能只有其中的一些，他們可能還在和你在一起工作，所以你可以把他們當做資源。如果你很不幸，可能有幾十個你以前從未聽說過的提交者。

無論如何，嘗試了解主要貢獻者是誰。如果你遇到一個奇怪的功能，並且你不能搞明白，請使用 git blame 找出提交者，找到他或她去詢問。

使用 git log 查看整個代碼倉庫的提交歷史記錄。此命令將列印提交消息，因此，如果要執行類似搜索提交消息中引用 someFunction 的提交，請勿忘記使用 grep 命令：git log | grep someFunction -C 3（-C 3將顯示匹配到的上下文三行內容）。

git log 還可以顯示具有 -p 標誌的單個文件的歷史記錄：git log -p index.js。 注意最近一直在修改代碼的人，這樣你就能知道在出現問題時找誰諮詢了。

-2-

Go Back in Time

你可以查看任何所需的提交，並將其運行，就像它是項目中最近提交的一樣。你可能在遇到一些想難以追蹤的錯誤出現時查看最後一次已知的正確的提交，或者你可能會覺得無聊和有心情探索下在你進該項目之前幾年裡該項目的歷史更新情況。

如果你的項目託管在 GitHub 或類似的網站上，你可以通過閱讀問題、pull 請求和代碼複審來獲得大量的信息。格外留意產生最大討論的問題。這些可能是你最終會遇到的痛點，你會提前知道如何處理它們。

-3-

閱讀規範

規範是新的注釋。 閱讀單元規範，以確定什麼功能和模塊是被支持的以及哪些邊界情況要被處理。 閱讀集成規範，以了解用戶如何與應用程序進行交互，以及應用程序支持哪些工作流程。

-4-

將評論視為提示

如果您遇到一個令人困惑的功能，然後閱讀了一個相關的評論，卻使您更加困惑，請考慮該評論過時且未被維護的可能性。 程序員的眼睛有一種跳過綠色線條文本的方法，這個沒有其他人注意到的評論可能是在說明這幾個月（或幾年）內不存在的迭代功能。

-5-

查看 Main 文檔

這可能看起來是很明顯，但請確保您知道代碼開始執行的位置以及如何設置。查看這裡包含的文件，正在實例化的類和正在設置的配置選項。

你可能會在代碼庫的其餘部分看到它們。這裡的一些模塊可能非常通用，並與其他代碼分離。它們代表更小，更易消化的功能，您應該在嘗試解決大型應用之前熟悉這些功能。

在這個文件上運行一個 git blame 命令，看看它最近有哪些部分被改變了。近期更改的一大堆代碼可能會告訴您最近幾周開發團隊面臨的一些挑戰，也許他們已經推出了一個新的庫，也許他們一直在努力地配置一個運行不太好的庫，或者也許只需要定期更新的樣板代碼。

嘗試在某些其他源代碼中查找對這些模塊的引用，以感受一下這些模塊是如何被使用的。這可以幫助您了解如何適應整個應用程序。

-6-

關注代碼風格

你正在學習這個應用程序的原因，是由於你最終要為它編寫代碼，所以要注意代碼風格。當然，這包括表面的東西，如命名約定、間距約定和大括弧放置，但這些都也包括代碼約定中。

一般的抽象層次是什麼？如果它是具有很多層次的高度抽象代碼，那麼你應該也希望編寫同樣的代碼。

如果你挖掘足夠多的代碼歷史版本，你可以找到一個確切的時間點，選擇其中一個開發人員一段代碼查看。查看以前這段代碼原來看起來是怎麼樣，以後怎麼樣？在編寫代碼時，嘗試遵循共同的約定。

在更微觀層面上，其他團隊成員使用什麼樣的代碼來完成任務？如果開發人員傾向於使用 map 的 for 循環，那麼您也應該傾向使用 map 的 for 循環。

如果你遇到一個你不喜歡的約定，請告訴你的團隊關於未來可能會改變約定，但不要在同一個文件中混合和堆砌一堆不同的樣式。讓一個文件看起來像一個人寫的越多越好。代碼風格一致性是比好看更重要的。

-7-

期待找出無用的代碼

你可能會發現一些永遠不會使用的函數，或者你可能會發現從未使用過的整個文件。 你可能會發現在幾年來沒有被碰過的注釋掉的代碼（git blame）。 不要遲疑，不要花太多時間去思考，不要害怕去掉這些東西。

如果代碼是由於某種原因出現的，會有人在代碼評審中標記該代碼。你的行為還會減少下一個讀者的心理開銷。

-8-

不要迷失

記住這些事情，當你發現自己周圍一片荒蕪時，不要感到不舒服。不要指望它是一個線性過程，並且不要期望理解全部的 100％。注意重要的細節，知道如何挖掘你的問題的答案，你會發現自己能很快理解。

小編拉你進粉絲微信群

不是在文章評論里回

點擊展開全文

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