閱讀優秀程式碼是提高開發人員修為的一種捷徑

　　原文作者Alan Skorkin是一名軟體開發人員，他在部落格中分享對軟體開發相關的心得，其中有很多優秀的文章，本文是其中的另一篇。Alan認為：閱讀優秀程式碼是提高開發人員修為的一種捷徑。以下是全文。

　　我突然想起來，很多程式設計師都討厭閱讀程式碼。來吧，承認吧！ 每個人都喜歡編寫程式碼，編程式碼是件趣事。 另一方面，閱讀程式碼也不容易。 不僅不容易，而且還非常枯燥，我們們要面對這一事實。任何不是你的程式碼都不怎樣。（雖然我們沒有說出來，但我們都是這樣想的。）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　編者後話

　　你會經常去閱讀優秀的開原始碼麼？歡迎在評論中和大家分享，也歡迎大家推薦優秀的開原始碼。

　　原文作者：Alan Skorkin　　編譯：伯樂線上 – 黃利民