全文共3624字，預計學習時長7分鐘

從Redis截取下來的代碼段

如果有一天醒來，你決定要成為一名偉大的作家，那麼你會得到兩個簡單的建議：不停地寫，然後不停地閱讀。

在軟件工程行業，很多人都會編寫代碼，但很少有人花時間閱讀代碼，特別是在日常工作之外的代碼，這是錯誤的行為。在職業生涯早期，你應該表現得像一個作家，抓住機會去閱讀各種代碼。

廣泛並頻繁地閱讀，這可能是一般的軟件工程師與卓越的軟件工程師之間的區別吧。

為什麼要閱讀代碼呢？

偉大的作家是由他們所讀過的作家造就的。例如，瓊·狄迪恩，16歲便能打出海明威所寫的句子，於是她學習到如何寫句子。或者亞伯拉罕·林肯，後來所寫的抒情詩就受到了他心愛的《聖經》（詹姆士王譯本）的啟發。

同樣，查看不同的編碼實踐練習會讓你在編寫代碼時想法更加豐富，而閱讀他人代碼也會讓你瞭解新的語言功能以及不同的編碼風格。

閱讀依賴板塊將使你成為更高效的程序員。你將瞭解依賴項提供的完整功能，確切地知道它們是如何工作以及進行權衡的。當出現問題時，你會知道如何調試。

以輕鬆心態閱讀代碼還可以避免過於篤定自身所編寫的代碼。你讀的代碼越多，那麼當推廣他人編寫的代碼時，你就會更加包容，而非建立自己的代碼。這種改變將降低你被“非在這裡發明”綜合症所困擾的可能性。

無論是網頁開發人員、數據工程師還是密碼學家，培養定期閱讀的習慣都會讓你學新的工具和產品，不同於日常工作的所見所聞。

作為一位網頁前端工程師，讀取光線跟蹤器代碼庫的一小部分將使你看到完全不同的約束集。作為一名數據庫工程師，閱讀一些十分抽象的網頁代碼可以向你展示用戶的想法。對所有工程師而言，你將找到定期閱讀每天一定量的工作語言之外的語言的價值所在。

正如唐納德·克努特所言，“[閱讀代碼]十分有益，因為它可以啟迪思維。閱讀他人的作品越多，你就越有能力在未來創造屬於自己的......”

以下會教你如何在閱讀自身代碼時感到儘可能地輕鬆與高效。

如何閱讀代碼？

找到代碼庫——像讀一本典型的書一樣從頭到尾地閱讀——這是失敗的嘗試（但諷刺的是，這也就是計算機閱讀代碼的方式）。

從頭開始閱讀意味著你會忽略一些重要內容，對即將到來的結構毫無頭緒。被動閱讀——你不編寫測試或者修復錯誤的代碼——會阻止你真正將代碼內化。

與書不同，幾乎所有的朋友都在努力地嘗試讀代碼，但是他們的腦海裡卻沒有特定的目標。在閱讀新的代碼庫之前，請確保好你有想要實現的目標。這將使代碼庫看起來更易於管理，並在旅途不可避免地變得艱難時提供動力。

可以用四種方法來處理任何複雜的代碼庫（簡稱RSDW）：

· (R)un運行: 編譯、運行並且理解代碼應該執行的操作。

· Examine(S)tructure 檢查結構：學習一些高級的結構和檢查關鍵的整合測試。

· (D)ive in跟尋：遵循關鍵流程並閱讀重要的數據結構。

· 編寫測試： 編寫測試並確定簡單功能和修復錯誤。

RSDW方法是一個起點，但隨著時間推移，你應該將其自定義為適合自己的方法。有些人發誓只寫測試和修復錯誤，而他人總喜歡從檢查整合測試開始。

不過，首先，還是要從RSDW方法開始。

1. 運行（Run）

閱讀代碼的第一步不是實際地去讀取代碼，而是去使用軟件。當你瞭解了軟件所提供的功能以後，才能去閱讀代碼。在這個階段，你應該能夠對代碼進行一個總結，並且對輸入和輸出有一定的瞭解。使用該軟件會強制你運行它。這意味著跟蹤依賴關係，在某些語言中，編譯代碼。對於圖書館來說，這意味著要調用一些流行的功能。這是運行測試並查看輸出消息的時間。如果第一次無法運行系統，那麼現在是記錄他人運行軟件實際需要的最佳時機。

2. 結構(Structure)

接下來，確定代碼中最關鍵的部分。這個過程是與閱讀一本書最不同的部分。你必須轉換思維來識別代碼中的關鍵聯繫，而不是從頭再開始。首先要了解代碼的結構。至少，運行一些自動化工具（例如tree和cloc）來找出代碼庫的語言和文件。找出關鍵的文件，看看修改的文件，並使用其它任何先進的工具查看最重要的集成測試，列出調用的函數。標記這些測試供以後使用。還有一種簡單的方法可以將此過程簡化：找到之前處理過代碼的人。理解結構是白板會議的首要任務。

3. 深入瞭解（Deep Dives）

一旦有一塊土地，就儘管去挖掘。

閱讀代碼時，你應該查看代碼流（查看正在創建的操作）並查看數據結構/對象（存儲操作結果的位置）。

在你發現的一些關鍵的整合測試，重要的模式識別學會中或者在對源文件的檢查中選擇三到五個關鍵流程，然後深入地去了解。我們應該從特定操作的最頂端開始並跟蹤代碼。一些開發人員非常相信調試器可讓你逐步完成這些代碼。其他開發人員更喜歡構建統一的建模語言（uml）圖或者火焰圖。

FlameGraph（火焰圖）資料來自於FlameGraph Repository

統一塑模語言（uml）, 過程流動圖，資料來自於維基百科

統一塑模語言（uml）,數據結構

在其他時候，你可以停在一個重要的功能中間的斷點處，然後在這一堆數據中工作，目的是瞭解你是如何到達那裡的。如果你決定手動跟蹤代碼，請確保編輯器的設置，使用“轉到定義”和“查找所有引用”的快速導航。

對於數據結構，請檢查數據類型以及何時設置關鍵變量。使用調試器在關鍵時刻查看這些數據結構。除了整合測試外，查閱重要的“pull”請求是一種處理新代碼庫的有效方法。永久性數據通常更容易理解，因為它封裝了獨立功能，並且提供了除代碼添加的原因和方式之外的敘述背景。

在深度瞭解期間，保持打開兩個markdown文檔，第一個是“升級編碼”文檔，列出正在看到的新語法和覺得有趣的代碼模式（其他人稱之為詞彙表）。第二個是列出了對代碼庫開發人員所提出的關鍵問題的文檔。 在這個階段，需要注意到差距，還會添加文檔。

4. 編寫代碼（Write Code）

在文學中，閱讀和寫作指的是不同的方向，與其不同的是，“閱讀”代碼的關鍵部分在於編寫代碼。沒有編寫代碼，內化代碼庫幾乎是不可能的。這兩種簡單的方法是編寫測試並解決簡單的功能/錯誤。寫作測試是一種積極的閱讀形式，迫使您特定交互的實際輸入和輸出。編寫測試以一種單獨讀取的方式在記憶中打印代碼。

單元測試是一種簡單的方法。一旦掌握了基礎知識，你就可以轉向整合測試，迫使自己理解代碼庫中越來越多的部分。有時候甚至會重寫現有的整合測試，來測試對關鍵工作的理解。

另一種簡單的方法是編寫簡單的功能或解決容易出錯的問題。這兩項任務都不需要完全瞭解代碼庫，但仍然迫使你面對代碼。提供錯誤修復和文檔也是回饋依賴關係的簡單方法。當你極其需要它時，這些方法可以快速獲勝。通過在一些更廣泛的課程中增加RSDW，閱讀代碼將變得不那麼令人生畏。

閱讀提示

該RSDW過程不是教條。工程師不可避免地想出了他們喜歡挖掘新代碼庫的個人方式（這個過程也因語言，可用的工具以及你面前的代碼庫類型而有很大差異）。

儘管如此，當你看到新代碼時，RSDW流程確實提出了一種系統方法。它鼓勵對代碼進行主動內省，無論是編寫測試還是主動使用調試器來查詢數據結構。 閱讀代碼的過程與閱讀書籍的被動過程大不相同。

閱讀新代碼很費時費力。你正在錯綜複雜地回溯代碼流並嘗試同時擁有數十個新的數據結構和功能。當你接近新的代碼庫時，要休息一下。開始使用新的代碼庫時，需要一整天的閱讀時間才能感覺到高效。雖然培養良好的閱讀技巧至關重要，但對於你所閱讀的內容進行深思熟慮同樣重要。

應該讀什麼代碼呢？

職業生涯早期，你應該花60％的時間閱讀代碼。也許其中三分之一應該是你實際構建的直接代碼庫之外的代碼。這是一個需要非常多的時間來填補的事情，所以你應該讀什麼呢？

開始閱讀的最簡單方法和最高投資回報率是學習依賴關係。把依賴工作內化的方式可讓你更輕鬆地在整個系統中進行調試和推理。另一個高投資回報率路徑是選擇與你交互的公司的重要系統，並通讀它。這不僅對你的工作非常重要，而且關鍵的是，專業代碼庫與開源代碼庫不同。除了與你互動的直接系統外，還要廣泛地開放性地閱讀。在我職業生涯早期，我建議你在早上或晚上留出一個小時來閱讀日常工作之外的代碼。經過一天辛苦的工作後，這聽起來很痛苦，但選擇一個令人興奮的代碼庫並嘗試閱讀。

例如，Redis被稱為C中的重要起點。對於不太可讀的並且更復雜的代碼庫，這種簡單的啟動方式是讀取特定的子系統。

輔助項目是一種很有影響力的閱讀方式，因為它們會迫使你接觸一個不一樣的世界。你需要閱讀新的依賴項並探索現在正在構建的不同代碼庫。雖然它看起來不像是閱讀，但這是一個迫使你積極閱讀你將要使用內容的方式。

在外面工作時，你應該閱讀與你日常工作大不相同的東西。如果你已經習慣了這種高層次的抽象，學習一個抽象度比較低的（或三級）。如果你是專注於一種語言，那麼請在空閒的時候選擇另一種語言來閱讀。如果你一直不得不考慮一個限制問題（例如，圖形編程中下一次屏幕刷新的時間），那麼找到另一個約束問題（例如，在移動編程中節省電池壽命）。

閱讀代碼的另一個好方法是閱讀和重寫所尊重的碼農所寫的東西。去閱讀他們的代碼庫並且去及時瞭解他們最近的工作。

斯蒂芬·金曾經勸告作家們，“如果沒有時間閱讀，你就沒有時間（或工具）來寫。這就是那樣簡單。“同樣，對於軟件工程師來說，編寫新代碼可能是最有趣的，但主動地積極地閱讀代碼會將你從束縛中逃離出來。

留言 點贊 關注

我們一起分享AI學習與發展的乾貨

歡迎關注全平臺AI垂類自媒體 “讀芯術”