- 原文：How to read code – a primer
- 原文作者：technikhil
- 譯者：newbiewang
- 校對者：陳元
我喜歡程式設計，它也是我的工作，而且我很高興能夠將大部分的時間都花在開發軟體上。像許多程式設計師一樣，我既著迷但又困惑的是，我寫的程式碼到底怎麼樣，以及如何寫得更好。
多年來，我已經閱讀了許多有關軟體開發的文章和書籍。其中不乏有許多墨寶（書上的或者網上的）告訴你如何提高程式設計，併成為一個像忍者一樣的受過專業訓練的程式設計高手！這些建議大多有一些共性，其中之一就是閱讀原始碼。然而相比於其它建議，閱讀原始碼通常也就是簡單的一句話來概括：找一些很棒的開源軟體，或是任何你喜歡的軟體，開啟它們（或列印出來）然後閱讀它們。雖然總的來說，這確實是個很好的建議，但紙上得來終覺淺，實際去實踐的時候才發現問題多多。在這篇文章中，我會嘗試給出一些閱讀原始碼的實用建議，但在這之前，首先讓我們列舉一下都有哪些問題。
對閱讀原始碼的誤解
別人一說閱讀原始碼，給你的一般印象似乎他們就像程式設計大師一樣，可以單純地坐在椅子上，然後像看小說一樣讀著手上的程式碼。好吧，我敢肯定，確實有一些精湛的程式設計師，他們可以很享受地一邊喝著咖啡、一邊看著一堆類似英語句子的神祕符號，並且還能夠在腦海裡構建整個類的層次和體系結構。顯然這篇文章並不是給他們看的，它的受眾是像我一樣的，覺得盯著一堆原始碼看就好比看一些無聊沒有意義的練習題的人。當然，有人會爭辯說，可以從一個完整專案裡一點一點地看單個類或者單個函式來學習，但在我看來，除非是最簡單的問題，大多數軟體內部都是相互依賴的。在不瞭解系統其餘部分的情況下，通常不可能理解一個特定函式或者類背後的設計思想和原理。
下一個問題是從哪裡獲得可以讀的原始碼（當然，在此之前，你得能夠鑑別哪些原始碼值得一讀）。優秀的軟體很多，既有開源軟體可以免費獲得，也有閉源軟體需要授權。開源倉庫有譬如 Sourceforge 和 GitHub 。如果你在軟體開發公司工作，那麼可以訪問原始碼庫中的專有程式碼。第三種常見途徑是軟體開發書籍附帶的程式，或者作為教育資源而提供的程式（ Minix 是典型的例子）。確實，眾多的選項使我們難以抉擇，因此從茫茫程式碼世界中找出適合我們閱讀的是一項艱鉅而必不可少的任務。
另一個問題是程式所用的程式語言，讀他人的程式碼已經足夠困難了，如果同時還需要去熟悉一門夾雜著奇葩語法的新語言，它所帶來的負擔，在我看來簡直就是個會帶來極大挫敗感的災難。所以你需要找到用你熟悉的語言所編寫的程式碼。但如果你要看的程式碼是來自書本上或作為教育資源所提供的，那懂不懂這門新語言並無關緊要，因為有導師可以解釋上下文。倘若你明知山有虎偏向虎山行，在沒有書或者導師指引下，去閱讀一門並不熟悉的程式語言，那我建議你至少需要學習，並達到可以寫出自己的程式的程度（Hello World 就不算了哈）。
前文有關上下文的問題使我想到了下一個問題，如果你不熟悉軟體本身，弄清楚程式碼在做什麼就困難得多。例如，如果你不是每天都在使用 Linux 並知曉 Linux 啟動順序，那麼就很難在看一邊 Linux 程式碼後弄清楚執行級別是什麼。使用某個軟體獲得的經驗、知識能夠幫助我們更好地閱讀它的原始碼，這包括常用的術語、軟體的功能和特性，甚至包括你遇到的各種錯誤本身。
理解原始碼
對我而言，我意識到 “閱讀原始碼” 並不能準確描述我所從事的活動，用 “理解原始碼” 來表述會更合適。對我來說，坐在筆記本螢幕前（或列印成紙），只是單純地讀滿屏的程式碼是非常困難的。我需要程式碼之外其它的東西，比如我喜歡翻一翻文件，玩一玩這個軟體，單步執行程式碼甚至寫測試程式碼去跑一跑，然後才能真正欣賞它。因為我會為此投入非常大的時間和精力，所以我必須要精挑細選，尋找我要 “閱讀”（理解）的軟體。
我的第一層過濾是通過程式語言進行篩選，對我來說，我只閱讀由 C#、VB.NET、Python 和 Javascript 編寫而成的程式的程式碼（儘管我也熟悉 C++、Ruby 和 F#，但我並不認為自己有水平來理解其他人的程式碼）。接下來是尋找我使用過的軟體，這會讓我有種已經上車的感覺，因為我知道程式碼的意圖，以及它不能做的事情還有它的侷限性（如果我足夠熟悉的話）。每天都在使用的開源軟體正是優秀的候選項（比如，我使用用 C# 編寫的開源工具 Cruise Control.NET、NANT 和 NUnit）
碰巧我在一家軟體產品公司（一家微軟的公司）工作，所以我閱讀的原始碼選擇項之一是我們公司在原始碼庫中的程式碼。如果碰巧你也在一家軟體公司工作，你可以檢視其他的專案，甚至你著手專案的較早期版本。這樣，除了可以獲得更深層次的程式碼理解之外，你還可以很好地瞭解之前和之後都曾嘗試過哪些東西。不過有一些警告需要注意：
- 首先，如果你沒有許可權訪問其他專案，則需要徵得許可，因為一些公司對其 “智慧財產權” 非常看重。
- 其次，這些軟體的質量可能沒有你想像的那麼高，因為通常情況下，專有程式碼沒有經過像開原始碼那樣嚴格的程式碼走查。需要注意的是，如果缺乏常規的程式碼審查，那麼程式碼的質量可能不佳。
- 第三（這一點是從我的朋友提供的反饋中得到啟發的），如果你的公司開發的是商業軟體（HR、財務、ERP 等），則需要首先理解很多業務關係。而且，由於大多數程式碼受業務功能因素的影響，因此通常模組化程度不如應用程式或 API 高。
尋找文件齊全的專案（這適用於開源以及專有程式碼）。我的意思是說，這樣的文件應該突出總體設計，並說明程式碼背後的原理。如果只是簡單地自動生成的 Java Doc 型別文件，則不能視之為我所描述的文件 ?。其中一種尋找途徑是利用為教育而創造的軟體（例如 Minix）。由於它們的目的是通過軟體進行教學，因此通常會有非常清晰的文件記錄下來，並且有大量資料解釋程式碼背後的設計原理。
總結
那麼，現在你已經確定了要閱讀原始碼的軟體並下載了它的原始碼和文件，讓我們一步步閱讀並理解它：
- 瀏覽設計文件，並嘗試瞭解程式碼的構建方式。好的軟體專案遵循某些架構模式，這些決定了程式碼的組織。一旦掌握了這一點，理解程式碼就變得容易了很多。如果你還能畫出類圖，就能更好地瞭解整體佈局。
- 接下來要做的是編譯並執行它。根據專案及其文件循序漸進，這可能很簡單也可能很困難。
- 現在是時候開啟你喜歡的 IDE 並開始探索了。一個好的探索起點是，嘗試一步步瀏覽你熟悉的功能的程式碼。這樣一來，你可以遍歷各個層和子系統，並瞭解它們之間的關聯。例如，當我探索 NUnit 時，我首先編寫了一個測試用例，然後檢視涉及到的類。
- 嘗試確定程式碼中使用的設計模式。如果你還不知道什麼是設計模式，那麼立刻馬上停止看本文，轉去閱讀設計模式的經典書籍。熟悉設計模式，它們是識別和理解優秀程式碼中所包含的設計的好方法。熟悉之後就可以更輕鬆地在閱讀程式碼時將其牢記在心。它還可以幫助你更輕鬆地識別程式碼作者在原有設計模式上所做的細微調整和魔改。
- 嘗試為程式碼編寫測試用例以完全理解它，這是理解程式碼不同部分之間的依賴關係的一種非常有用的方法。寫測試用例之前，首先需要滿足所有的依賴。接下來，瞭解程式碼的可能的入口點和返回值。這可以增進你對程式碼的理解，助你更上一層樓。
- 最後，嘗試重構程式碼。在這一步，你已經從單純地理解程式碼邁向足夠熟悉以能夠對其進行修改。隨著重構複雜程度的提高，你的理解也將隨之增加。此時，如果需要，你可以為專案貢獻自己的程式碼。
“原始碼閱讀”在我看來，不僅僅是閱讀，它是一組獨特的活動，共同幫助人們理解程式碼。這似乎比簡單的 “閱讀程式碼” 更令人生畏，但它值得付出努力。
現在，你可以更加輕鬆，快樂地“閱讀原始碼”了嗎？?