閱讀優秀代碼是提升開發人員修爲的一種捷徑（轉載）

原文做者Alan Skorkin是一名軟件開發人員，他在博客中分享對軟件開發相關的心得，其中有不少優秀的文章，本文是其中的另外一篇。Alan認爲：閱讀優秀代碼是提升開發人員修爲的一種捷徑。如下是全文。我忽然想起來，不少程序員都討厭閱讀代碼。來吧，認可吧！ 每一個人都喜歡編寫代碼，編代碼是件趣事。 另外一方面，閱讀代碼也不容易。 不只不容易（編注：參見《微軟資深軟件工程師：閱讀代碼不容易》）， 並且還很是枯燥，我們要面對這一事實。任何不是你的代碼都不怎樣。（雖然咱們沒有說出來，但咱們都是這樣想的。）

編者按：即使是你本身幾個小時以前寫的代碼，也會看起來很爛。時間越久，看起來越爛。 因此，爲何你要浪費時間去看其餘人的糟糕代碼，而你徹底能夠利用這段時間編寫你本身的優秀代碼。 其實咱們能夠一試，幾個小時以後回頭再看，看看你的代碼是否還依舊優秀。 若是你不能吸取前輩大師的經驗知識，那你永遠都沒法成爲一位大師。 成爲大師的方法之一是，找到一位大師，讓其傾囊傳授其所知。 有這種可能麼？固然了，有這可能，雖然機會不大，但你必須極其走運。 不過你沒必要十分走運，由於咱們幸運地處於這樣一個職業，一個充滿着大師知識和技能的職業，等待咱們去汲取吸取，這些東西就在他們所編寫的代碼中。 你要作的就是去閱讀代碼，固然了，這或許耗時很多，畢竟沒有人坐在那裏給你講解，但這種方法的成效還很高。 打個比方，要想成爲一名卓越的木匠，得觀察大量結構優良的傢俱。

我喜好閱讀代碼，個人直覺告訴我，你也會從中獲益頗豐。雖然閱讀過程惱人並煩人，但其回報是很是值得你爲之努力的。 說到這個，若是你想成爲一名卓越的做家，你會專一於寫做麼？ 你或許已經嘗試，但你並無走得很遠。 大多數的偉大做家也是如飢似渴的讀者，這是一個廣泛事實。 在你能寫出任何拿得出手的東西以前，你須要品讀其餘偉大做家，吸取不一樣的風格，看看前輩已嘗試過的東西，從中吸收精華。 你的知識會慢慢增加，你本身的做品最終會透露出些許成熟，你也會找到一種「感受」。 編寫代碼和寫做沒什麼不一樣，若是你都沒有閱讀過任何卓越的代碼，你爲何指望本身能寫出像樣的代碼呢？ 你顯然不該該那樣。對於程序員來講，閱讀卓越代碼就如同做家閱讀優秀書籍同樣重要（這話可不是我說的，這是Peter Norvig（Google研究院總監）說的，他很是優秀，你們也要向他學習了）。

即使全部這些都沒法讓你信服，那這裏有一個不可置否的事實。 對你做爲一名專業開發人員的生存來講，善於閱讀代碼相當重要。 現在，任何有必定規模的項目，都是團隊的成果。因此，你一般要處理、修改和擴展大量不是你寫的代碼。 所以，閱讀代碼多是你能掌握的最經常使用並最有用的技能。挺過這個難關，好好掌握。

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

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

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

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

3. 確信本身理解全部結構。 除非你碰巧是所用編程語言的首席專家，不然該語言有些它能作的事你可能還不知道。當你在瀏覽代碼時，記下全部你或許不熟悉的結構。 若是有不少不熟悉的結構，你要作的下一步很是明顯。 若是你不知道代碼要作什麼，那你就走不了很遠。 即使只有幾個你不熟悉的結構，你應當深刻查看。 你如今是在探索你所用編程語言中你之前不知道的東西，爲此花幾個小時來閱讀代碼，我也很是樂意。

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

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

6. 若是你說沒有測試，那這聽起來是編寫測試的時候了。 （編寫測試）有不少益處，有助於你本身的理解，有助於你提高代碼庫，閱讀代碼時也能編寫代碼，這是該你出手作些事的時候。 即使已經有了測試，一般你也能夠編寫一些測試，你總能受益的。 測試代碼一般須要換種方式思考問題，那些你之前不太明瞭的概念也會變得更清晰。

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

8. 代碼不乾淨？有異味？ 爲何不重構它？ 我並不建議你重寫整個代碼庫，但重構部分代碼，真的有助於你理解層次上升一層。 把你理解的函數拿出來，改爲獨立的函數。 在你知道以前，原來的大函數看起來易管理，你能夠在腦海中修改它。 重構容許你把代碼變成本身的，無需完成重寫代碼。 若是有好的測試，有助於重構，但即使你沒有好的測試，抽取你肯定的函數並作測試。 即使測試看起來徹底不充分，但做爲一個開發人員，你得學着相信你的技能，有時候你只需努力去作（重構）。（若是你必須重構，你一般均可以把代碼恢復原 狀。）

9. 若是沒什麼能幫上忙，那你就找個閱讀代碼的同伴。或許並不是只有你一我的能從這代碼中獲益，因此去找一個 人，一塊兒閱讀代碼吧。 但你別找專家，他們會從上層結構上，向你解釋全部東西，你會錯失那些你本身詳細查看代碼時所能學到的細微差異。 然而，若是不見效的話，你也不能理解，有時候，你能作的最好的事就是去問。 向你的同事請教，若是你正在閱讀開源代碼，能夠在互聯網上找人問問。 可是你要記住，這是最後一步，而不是第一步。

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

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

咱們喜歡編寫新代碼，是由於咱們此次能正確處理問題。 好吧，也許不是此次，但必定是下次。 事實上是，你常常改進你的技術，但你從沒有恰當地處理問題。 這就是編寫新代碼的價值所在，你能夠歷練並磨練你的技能，但閱讀和把玩其餘人編寫的代碼，（若是沒有更多的價值，）也是有一樣多的價值。你不只能從中得到一些有價值的技術知識，也能收穫領域知識，領域知識一般仍具更多價值（畢竟，代碼是文檔的最終形式）。

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

編者後話

你會常常去閱讀優秀的開源代碼麼？歡迎在評論中和你們分享。