站長資訊網
相關學習推薦：javascript
我喜歡編程，它也是我的工作，而且我很高興能夠將大部分的時間都花在開發軟件上。像許多程序員一樣，我既著迷但又困惑的是，我寫的代碼到底怎么樣，以及如何寫得更好。
多年來，我已經閱讀了許多有關軟件開發的文章和書籍。其中不乏有許多墨寶（書上的或者網上的）告訴你如何提高編程，并成為一個像忍者一樣的受過專業訓練的編程高手！這些建議大多有一些共性，其中之一就是閱讀源碼。然而相比于其它建議，閱讀源碼通常也就是簡單的一句話來概括：找一些很棒的開源軟件，或是任何你喜歡的軟件，打開它們（或打印出來）然后閱讀它們。雖然總的來說，這確實是個很好的建議，但紙上得來終覺淺，實際去實踐的時候才發現問題多多。在這篇文章中，我會嘗試給出一些閱讀源碼的實用建議，但在這之前，首先讓我們列舉一下都有哪些問題。
對閱讀源碼的誤解
別人一說閱讀源碼，給你的一般印象似乎他們就像編程大師一樣，可以單純地坐在椅子上，然后像看小說一樣讀著手上的代碼。好吧，我敢肯定，確實有一些精湛的程序員，他們可以很享受地一邊喝著咖啡、一邊看著一堆類似英語句子的神秘符號，并且還能夠在腦海里構建整個類的層次和體系結構。顯然這篇文章并不是給他們看的，它的受眾是像我一樣的，覺得盯著一堆源碼看就好比看一些無聊沒有意義的練習題的人。當然，有人會爭辯說，可以從一個完整項目里一點一點地看單個類或者單個函數來學習，但在我看來，除非是最簡單的問題，大多數軟件內部都是相互依賴的。在不了解系統其余部分的情況下，通常不可能理解一個特定函數或者類背后的設計思想和原理。
下一個問題是從哪里獲得可以讀的源碼（當然，在此之前，你得能夠鑒別哪些源碼值得一讀）。優秀的軟件很多，既有開源軟件可以免費獲得，也有閉源軟件需要授權。開源倉庫有譬如 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 時，我首先編寫了一個測試用例，然后查看涉及到的類。
- 嘗試確定代碼中使用的設計模式。如果你還不知道什么是設計模式，那么立刻馬上停止看本文，轉去閱讀設計模式的經典書籍。熟悉設計模式，它們是識別和理解優秀代碼中所包含的設計的好方法。熟悉之后就可以更輕松地在閱讀代碼時將其牢記在心。它還可以幫助你更輕松地識別代碼作者在原有設計模式上所做的細微調整和魔改。
- 嘗試為代碼編寫測試用例以完全理解它，這是理解代碼不同部分之間的依賴關系的一種非常有用的方法。寫測試用例之前，首先需要滿足所有的依賴。接下來，了解代碼的可能的入口點和返回值。這可以增進你對代碼的理解，助你更上一層樓。
- 最后，嘗試重構代碼。在這一步，你已經從單純地理解代碼邁向足夠熟悉以能夠對其進行修改。隨著重構復雜程度的提高，你的理解也將隨之增加。此時，如果需要，你可以為項目貢獻自己的代碼。
“源碼閱讀”在我看來，不僅僅是閱讀，它是一組獨特的活動，共同幫助人們理解代碼。這似乎比簡單的 “閱讀代碼” 更令人生畏，但它值得付出努力。
現在，你可以更加輕松，快樂地“閱讀源碼”了嗎？
想了解
