我突然想起來，很多程序員都討厭閱讀代碼。來吧，承認吧！ 每個人都喜歡編寫代碼，編代碼是件趣事。 另一方面，閱讀代碼也不容易。 不僅不容易（編注：參見《微軟資深軟件工程師：閱讀代碼不容易》），而且還非常枯燥，咱們要面對這一事實。任何不是你的代碼都不怎樣。（雖然我們沒有說出來，但我們都是這樣想的。）

即便是你自己幾個小時之前寫的代碼，也會看起來很爛。時間越久，看起來越爛。 所以，為什么你要浪費時間去看其他人的糟糕代碼，而你完全可以利用這段時間編寫你自己的優秀代碼。 其實我們可以一試，幾個小時之后回頭再看，看看你的代碼是否還依舊優秀。 如果你不能吸收前輩大師的經驗知識，那你永遠都無法成為一位大師。

成為大師的方法之一是，找到一位大師，讓其傾囊傳授其所知。 有這種可能么？當然了，有這可能，雖然機會不大，但你必須極其走運。 不過你不必十分走運，因為我們幸運地處于這樣一個職業，一個充滿著大師知識和技能的職業，等待我們去汲取吸收，這些東西就在他們所編寫的代碼中。 你要做的就是去閱讀代碼，當然了，這或許耗時不少，畢竟沒有人坐在那里給你講解，但這種方法的成效還很高。 打個比方，要想成為一名卓越的木匠，得觀察大量結構優良的家具。

我喜愛閱讀代碼，我的直覺告訴我，你也會從中獲益頗豐。雖然閱讀過程惱人并煩人，但其回報是非常值得你為之努力的。 說到這個，如果你想成為一名卓越的作家，你會專注于寫作么？ 你或許已經嘗試，但你并沒有走得很遠。 大多數的偉大作家也是如饑似渴的讀者，這是一個普遍事實。 在你能寫出任何拿得出手的東西之前，你需要品讀其他偉大作家，吸收不同的風格，看看前輩已嘗試過的東西，從中吸取精華。 你的知識會慢慢增長，你自己的作品最終會透露出些許成熟，你也會找到一種“感覺”。 編寫代碼和寫作沒什么不同，如果你都沒有閱讀過任何卓越的代碼，你為什么期望自己能寫出像樣的代碼呢？ 你顯然不應該那樣。對于程序員來說，閱讀卓越代碼就如同作家閱讀優秀書籍一樣重要（這話可不是我說的，這是Peter Norvig（Google研究院總監）說的，他非常優秀，大家也要向他學習了）。

即便所有這些都無法讓你信服，那這里有一個不可置否的事實。 對你作為一名專業開發人員的生存來說，善于閱讀代碼至關重要。 如今，任何有一定規模的項目，都是團隊的成果。所以，你通常要處理、修改和擴展大量不是你寫的代碼。 因此，閱讀代碼可能是你能掌握的最常用并最有用的技能。挺過這個難關，好好掌握。

如何閱讀代碼？像某些人一樣……

我已經記不清有多少次看到程序員（用鼠標）滾上滾下地看著不熟悉的代碼，幾分鐘過后，他們的臉上浮現出不悅的表情。 他們不久后會宣告說，那代碼不值一讀，為什么要浪費時間呢？我們只能用其他方法解決問題。 我不確定（他們）在期待什么，是通過潛移默化來吸收代碼的含義，還是集中精神盯著代碼來得到啟發？ 你不能只靠長時間盯著代碼來閱讀代碼，你要理解它并化為己用。 這里有一些我喜歡用的技巧，雖然這不是一份詳盡的列表，但我發現其中有些特別有用。

1.盡力構建并運行代碼。 這通常是一個簡單的步驟，就像你在看可運行的代碼（這和隨機代碼相反）。 不過，并非總是如此。通過構建和執行代碼，你能從中學到很多上層代碼結構。 說到工作代碼，你是否非常熟悉如何構建你的當前項目？ 雖然構建通常非常復雜，但通過構建并生成可執行的代碼，你能學到很多。

2. 不要只注重細節。 你要做的第一件事是，在你正閱讀的代碼中，找到代碼結構和風格的。 首先瀏覽一下代碼，盡力理解不同代碼段要做什么。這會讓你熟整個代碼的上層結構，你也能領會到你正處理的代碼的一些構思（良好架構和意大利面條等）。 這時候，你可以找到切入點（不管它是什么，主函數、servlet或控制器等），并查看代碼如何在那里分支。 不要在這上面花過多的時間，隨著你愈加熟悉代碼，你可以隨時回來查看。

3. 確信自己理解所有結構。 除非你碰巧是所用編程語言的首席專家，否則該語言有些它能做的事你可能還不知道。當你在瀏覽代碼時，記下所有你或許不熟悉的結構。 如果有很多不熟悉的結構，你要做的下一步非常明顯。 如果你不知道代碼要做什么，那你就走不了很遠。 即便只有幾個你不熟悉的結構，你應當深入查看。 你現在是在探索你所用編程語言中你以前不知道的東西，為此花幾個小時來閱讀代碼，我也非常樂意。

4. 既然你對大多數結構已有很好了解，那現在是該做些隨機深入研究了。 就像步驟2，開始瀏覽代碼，當這次要挑選一些隨機函數或類，并開始逐行詳細查看。 這是硬仗開始的地方，但也是你要取得主要成功的地方。 這里的構想，會形成你正在查看的代碼庫的思維模式。 也不要在這上面花過長的時間，但在繼續前行之前，你要盡力并極大吸收一些有內容的代碼塊。 這個步驟，你也可以隨時反復回過頭來，每次你都會了解更多的背景，并收獲更多。

5. 毫無疑問，在前面這些步驟中，肯定有你困惑的地方，所以這是你做些測試的最佳時間。在測試的時候，你的麻煩可能會更少，同時你也能理解代碼。 我一直感到奇怪，開發人員忽略一套寫得很好很全面的測試代碼，而盡力去閱讀并理解某些代碼。 當然了，有時候并沒有測試。

6. 如果你說沒有測試，那這聽起來是編寫測試的時候了。 （編寫測試）有很多益處，有助于你自己的理解，有助于你提升代碼庫，閱讀代碼時也能編寫代碼，這是該你出手做些事的時候。 即便已經有了測試，通常你也可以編寫一些測試，你總能受益的。 測試代碼通常需要換種方式思考問題，那些你以前不太明了的概念也會變得更清晰。

7. 提取奇特的代碼，使其成為單獨的程序。我發現閱讀代碼是個非常有趣的練習，即便只為節奏變化。 即便你不了解代碼的底層細節，你或許能知道一些代碼在上層結構上要做什么。 什么不提取一些特定的函數，單獨列為獨立的程序。 當你在執行小段程序時，調試也會更簡單。反過來說，可能還需要一些額外的步驟，才能理解你正查看的代碼。

8. 代碼不干凈？有異味？ 為什么不重構它？ 我并不建議你重寫整個代碼庫，但重構部分代碼，真的有助于你理解層次上升一層。 把你理解的函數拿出來，改成獨立的函數。 在你知道之前，原來的大函數看起來易管理，你可以在腦海中修改它。 重構允許你把代碼變成自己的，無需完成重寫代碼。 如果有好的測試，有助于重構，但即便你沒有好的測試，抽取你確定的函數并做測試。 即便測試看起來完全不充分，但作為一個開發人員，你得學著相信你的技能，有時候你只需努力去做（重構）。（如果你必須重構，你通常都可以把代碼恢復原狀。）

9. 如果沒什么能幫上忙，那你就找個閱讀代碼的同伴。或許并非只有你一個人能從這代碼中獲益，所以去找一個人，一起閱讀代碼吧。 但你別找專家，他們會從上層結構上，向你解釋所有東西，你會錯失那些你自己詳細查看代碼時所能學到的細微差別。 然而，如果不見效的話，你也不能理解，有時候，你能做的最好的事就是去問。 向你的同事請教，如果你正在閱讀開源代碼，可以在互聯網上找人問問。 但是你要記住，這是最后一步，而不是第一步。

如果我時間緊迫，需要快速合理地理解某些代碼，并且我只能挑選上述步驟的其中一個，那我會選擇“重構”（即：第8個步驟）。 雖然你能理解的東西不會很多，但那些你領會的東西，你會牢牢記住的。 總之，有件事你需要記在心里。 如果你新接觸一個重要的代碼庫，你不可能立即能理解它。 這需要數天、數周和數月的潛心努力，接受這個事實。 即便有一位專家和你在一起，也不能明顯地縮短時間（。 然而，當涉及到代碼庫時，如果你能耐心并有條不紊地閱讀（和編寫）代碼，你最終能熟悉項目的方方面面，你能成為大牛。 你或者是逃避閱讀代碼，經常尋求某人幫你講解某事。 我知道我會成為哪一種人。

尋找閱讀代碼的機遇 – 不要錯失

我們喜歡編寫新代碼，是因為我們這次能正確處理問題。 好吧，也許不是這次，但一定是下次。 事實上是，你經常改進你的技術，但你從沒有恰當地處理問題。 這就是編寫新代碼的價值所在，你可以歷練并磨練你的技能，但閱讀和把玩其他人編寫的代碼，（如果沒有更多的價值，）也是有同樣多的價值。 你不僅能從中獲得一些有價值的技術知識，也能收獲領域知識，領域知識通常仍具更多價值（畢竟，代碼是文檔的最終形式）。

即便代碼寫得很神秘，無任何慣例可言，但還是有價值。 你知道我在說的代碼，它幾乎看起來晦澀難懂，但不是有意而為之（因某些原因，Perl語言代碼通常是這樣的）。 不管什么時候我看到那樣的代碼，我都會這樣想： 把它想象成只有你破譯它后才能學到的東西。 是的，這是主要的痛楚之處，但要接受它，有時候你自己也會因瑣碎的原因而寫出那種使人困惑的代碼（否認沒有用，你知道這是真的）。 好了，如果你花些時間來閱讀那樣的代碼，你更有可能最終寫出同樣的代碼。并不說你將會寫出那樣的代碼，但你有能力寫出那樣的代碼。 最后，態度通常是最重要的（編注：態度決定一切）。 如果你視閱讀代碼為日常繁瑣的工作，那它就是（繁瑣的工作），并且你會逃避，但如果你視其為一個機遇，那好事終將到來。