我為何愛讀代碼？你為何也應當愛？（轉）

    很少看到關於寫代碼閱讀方面的文章，偶爾碰到，以作備份，並和大家共勉

 

我恨讀代碼

我發現，許多程式員都討厭讀代碼——拜託別掩飾了，承認吧。差不多每個人都喜歡寫代碼——寫代碼樂在其中。可是，讀代碼真是不容易，而且還很煩人，又無可逃避，其他人寫的代碼總是很垃圾（即便不說，我們心裡也這麼想的）。即使自己寫的代碼，過幾個小時再看也有點垃圾，過的時間再久點，就更垃圾了。那麼，還有什麼理由去看別人的蹩腳代碼，而是不自己寫幾手漂亮的。能不能暫且忽略這個問題，花上幾個小時看別人的代碼，再回頭來看自己的是不是還那麼漂亮。即便有位大師坐在你面前，如果你不能從他身上學習，你永遠也成不了大師。辦法之一就是找到這麼一位大師，讓他手把手地教會你全部知識。有這可能嗎。——當然有，只是很難遇到這頂好的運氣。不過你也不必奢求那麼幸運，做程式員這行就很幸運，因為大師們的所有思想和技藝都凝鑄在他們的代碼裡，供我們學習。你要做的只是閱讀代碼——當然，如果有人給你一點點地講肯定更節省時間，但這基本屬於癡人說夢。換句話說，要相當個好木匠，得仔細研究大量的精美傢具。

我熱愛讀代碼，我總是直觀地認為讀代碼的收穫很大，沒錯，它可能有點討厭甚至煩人，但你的收益絕對大過這點麻煩。舉個例子，你要當大作家，是不是只關心自己寫東西就夠了。你可以試試看，但是估計不會折騰不出什麼名堂。公認的事實是，多數大作家都是會如饑似渴大量閱讀的。想寫出好的作品，必須先閱讀其他大作家的作品，吸收不同的風格，瞭解他人的嘗試，然後才可以培養自己的創造力。這樣，你的知識才能逐漸積累，最終你寫的東西才有幾分成熟，你也才會找到“感覺”。寫代碼也是這樣，如果你不去閱讀那些偉大的代碼，怎麼可能把程式寫的漂亮。閱讀偉大的代碼之於程式員，就如同閱讀偉大作品之於作家（我不敢掠美，這句話是Peter Norvig(譯註：Peter Norvig是著名的Lisp程式員，現任Google研發總監)說的，他可不是個簡單人物，所以好好記住這句話吧）。

即使上面說的你都不信，但有個事實無可否認。要想當個稱職的開發人員，能熟練閱讀代碼是非常重要的。如今，只要不是鬧著玩的項目，都是團隊協作的成果，所以總會有這樣的代碼：它不是你寫的，但你必須跟它打交道，去修改，或者去擴充。於是，閱讀代碼很可能就是你身上最重要最常用的能力了，咬緊牙關練好這門本事吧——而且，要快。

要像…會讀代碼的那些傢伙一樣…閱讀代碼
我都說不清有多少次見過這樣的事情了：程式員把一段不熟悉的代碼上下拖動，幾分鐘之後仍然一臉迷離。不久他們就宣布，這段代碼根本沒法看懂，更不必浪費時間了，可以想辦法繞過這個問題。我不知道他們真正要做的是什麼，一點點弄明白這段代碼的意思，還是睜大眼睛等著開竅。閱讀代碼不靠成年累月死盯著看，你要做的是弄懂它，把它變成自己的。下面說的是我用的一些技巧，但不是全部，不過我覺得這些非常有用。

看代碼看到目光迷離

1. 嘗試親自構建和運行程式。通常這一步很容易做到，比如你看的是真正啟動並執行工作代碼時（而不是不知來源的古怪代碼）就是如此。不過也不是每次都很容易，如果不能很容易地構建和運行，你可以在完成構建和啟動並執行過程中，認識到代碼的高層結構。而且，閱讀工作代碼，你會非常熟悉如何構建項目。構建通常是複雜的，但是瞭解構建過程，知道代碼是如何變為可執行程式的，會大大加深你的理解。

2. 別死盯細節。讀代碼要做的第一件事，是找到對代碼的結構和風格的感覺。開始應當瀏覽，並且努力找出各部分代碼都在幹什麼。這樣你能熟悉整套代碼的高層結構，也會明白你正在看的是什麼樣的代碼（重構良好的，還是亂成一團的）。這時候你要做的就是找到入口（可能是main函數，也可能是servlet，controller之類），看看下面的分支是怎麼展開的。這一步不要花太多時間，你對全部代碼更熟悉之後，隨時可以退回來。

3. 確保理解所有構造（construct)。除非你非常精通這門程式設計語言，否則多半還有些東西是你不知道的。在概略瞭解代碼的階段，要記下每一個不熟悉的構造。如果這樣的構造有很多，下一步就不言自明了。如果搞不懂程式碼為的意義，你什麼也幹不了。即便你不熟悉的只是少數構造，仔細觀察推敲沒準也是好事。你可能會找到一些以前不知道的關於這門程式設計語言的知識，我就很樂意為此花上幾個小時。

4. 待熟悉了大多數構造之後，就可以搞幾次隨機的深入探查了。做法類似第2步，快速探索程式碼程式庫，但是這次要隨機抽幾個函數或者類，一行行地看下去。真正的考驗現在才開始，但你的收益也是從這一步開始顯現。主旨是：真正深入到你所閱讀的整套代碼的概念體系（組件結構）當中。這又是一個速度快不起來的步驟，但是在這一步，一定要嘗試深入理解若干繁雜的細節。和第2步一樣，在這一步，每次你多瞭解了一些上下文再回頭看看，你的理解就更深入一些。

5. 前幾步中肯定還有你不明白的地方，現在最合適的就是跑幾個測試，看看已有的測試。測試很可能會大大打消你的疑惑，加深你對所測試代碼的理解。我時常不能理解，為什麼有些開發人員在閱讀和理解代碼時，忽略嚴密而精巧的測試套件。當然，也有時候是因為沒有測試程式。

6. 如果沒有測試程式，這時候就該寫上幾個。這樣做有很多好處，它會加深自己的理解，它可以完善整個程式碼程式庫，在閱讀代碼的時候也在寫代碼，這樣對已有代碼和你都有好處，你也可以真正動手參與進去。即便有現成的測試程式，為了加深自己的理解，你也可以再寫一些。測試人家的代碼，一般要求換個角度思考，之前你感到迷惑的概念也會變得更清楚。

7. 把弄不懂的部分拿到單獨的程式中來。我發現，讀代碼時這樣做，哪怕只是為了調節閱讀的節奏，也是非常有樂趣的。即使你不理解代碼的底層細節，也可能會對代碼的功能有些高層面的想法。那為什麼不把一些功能抽到單獨的程式中測試呢。如果只運行一小段程式，debug就容易多了，而且這樣的過程反過來又會加深你的理解。

8. 代碼很亂（dirty）很糟糕（smelly）。那麼重構吧。我可不是建議你把整個程式碼程式庫推倒重來，但是重構一些部分確實可以讓你的理解更上層樓。一開始要做的是把你明白了的功能變為獨立的函數。在你真正理解之前，重構之前的函數只是看起來沒問題，而重構可以把它們變成你想要的樣子。依靠重構，你可以把代碼變成自己的，而不要全部重寫。好的測試程式可以幫上忙，不過如果你沒有，就一邊測試一邊重構吧，而且只改動那些你確認弄懂了的功能。即便測試看起來太少太不完善，也要相信你自己的開發水平，有時候你只管大膽嘗試就好（如果確實需要，總是可以回退(revert)的）。

9. 如果上面說的都不管用，就找個同伴跟你一起讀代碼。能從讀代碼中受益的可能並不只有你一個人，所以不妨抓住其他人，一起閱讀。不過別找專家，他們給你的解釋都是高層面的，這樣看代碼時注意的那些細節就都被忽略了。如果找不到人一起閱讀，你又實在看不懂，有時最好的辦法就是問別人。可以問你的同事，如果你在讀的代碼是開源的，也可以在網上問問其他人。記住，這隻是最後的辦法，不要一開始就這麼做。

如果時間很緊張，短時間內必須弄懂某些代碼，上面的步驟中只能選一步，我會選擇重構（第8步）。你可能沒法明白太多東西，但你肯定可以理解真正動過的部分。無論時間是不是緊張，你要記住的是：如果你第一次接觸重要的程式碼程式庫，肯定不能一下子就看懂，甚至不可能很快看懂。你可能需要耐心讀上幾天，幾周甚至幾個月——坦然面對就好。即便有專家坐在你身邊，也省不了太多時間（我寫的關於教和學的系列文章最後一篇就會談這個問題）。如果你讀（或者寫）代碼的耐心足夠，方法得當，你肯定能成為對項目所有方面都非常熟悉的人，也是大家對程式碼程式庫有問題時出面解答問題的人。你也可以不閱讀代碼，選擇成為那個總想找人來解釋的傢伙。我想要做哪樣的人，我自己很清楚。

抓住閱讀代碼的機會，別錯過
我們都喜歡新寫代碼，它的誘惑力在於，我們能搞定問題。起碼，這次搞不定，下次可以搞定。真相是：你在實踐中不斷提高，永遠不可能一下就徹底搞定。這就是新寫代碼的價值所在，你在練習，你的水平在提高，但是閱讀和改動其他人寫的代碼也很有價值（至少不亞於自己重新寫），從中你學習到的不光是有價值的技術知識，還有關於整個工作領域的知識（畢竟，代碼才是文檔的最終形式），這種知識通常更有價值。

每一段不遵循傳統的，莫測難懂的代碼，都是有價值的。你知道我說的是什麼，雖然它看起來一團糟，但本意並非如此（也可能因為它是Perl代碼:)）。每次我看到這樣的代碼，我都這麼想。不妨把閱讀它當作猜謎遊戲，想想你能學到什麼。是的，這很折磨人，但必須承認，你也希望能動手就能寫出這麼糟糕的代碼。如果你花時間閱讀這樣的代碼，你肯定更可能寫出這樣的代碼——這倒不是說，你一定會寫這樣的代碼，但你肯定希望自己能夠。最後要說的是，態度總是非常重要的。如果你把閱讀代碼看作閑雜事，那它就是閑雜事，而你肯定會逃避，但是如果你把它看成機會，事情就不一樣了。

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/bvbook/archive/2011/02/16/6187192.aspx