【本人禿頂程式設計師】阿里P7是如何高效閱讀原始碼，你學習到了嗎？
←←←←←←←←←←←← 快！點關注
“我討厭閱讀別人的程式碼”是所有經驗層級上的軟體開發人員之間普遍存在的問題。然而，這又是一個必要的技能，特別是對於開發人員進入到現有的程式碼庫中的時候，如果你以正確的角度和正確的工具來處理它，這可能是一個愉快和有啟發性的體驗。
我們討厭閱讀別人的程式碼的原因是因為程式碼不是我們自己寫的。這不是因為我們認為自己是地球上最好的編碼人員，沒有人可以像我們這樣編寫好的程式碼。而是因為在建立程式碼時有一個積極的思維過程，而被動的閱讀者並沒有獲得這種親身體驗的益處。
你在螢幕上看到的程式碼可能涉及多個人。它可能涉及辯論和協作。它可能需要幾個星期才能完成符合只在原作家頭腦中的一些未文件化的限制的版本——但是你對此卻不可得知。
作為讀者，你看到的所有產品都是成品，除非你做一點挖掘，否則你唯一得到的就是螢幕上的其他單詞。
1. 學會深挖
當你第一次深入成熟的程式碼庫時，你可能感覺自己不像開發人員。你可能更像是考古學家、私人調查員或聖經學者。這很好，因為你有一大堆事情需要處理。
如果你有幸能夠從一開始就接觸使用版本控制的程式碼庫，那麼就該慶祝一下。你可以訪問豐富的元資料，這將使你理解的不僅僅是程式碼，還包括上下文，都會容易很多。我會假設你使用 Git ，但是如果你使用 SVN ，那麼這個想法也是同樣適用的。
git blame
你可以在檔案上使用 git blame 來獲取每一行的提交名、上次修改日期和提交雜湊值。熟悉這些提交者。如果你足夠幸運的話，可能只有其中的一些，他們可能還在和你在一起工作，所以你可以把他們當做資源。如果你很不幸，可能有幾十個你以前從未聽說過的提交者。
無論如何，嘗試瞭解主要貢獻者是誰。如果你遇到一個奇怪的功能，並且你不能搞明白，請使用 git blame 找出提交者，找到他或她去詢問。
git log
使用 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％。注意重要的細節，知道如何挖掘你的問題的答案，你會發現自己能很快理解。