對於程序員來說除了寫代碼之外，很多的工作就是看別人寫的代碼了。
幾乎所有的文章都是圍繞如何去寫代碼，讀代碼的文章就相對很少。我自己在網上搜了一下結果也是這樣，那我和大家分享一下自己讀代碼的方法。我這裏談的不是三五個class那樣的程序，因爲這樣小規模的程序不需要太多的技巧，一行一行看下來基本就能搞懂了。
有時候在察看開源項目的時候，如果你想參與其中，那項目的負責人基本上都是建議從bugfix開始瞭解程序，瞭解代碼。所以第一個建議就是從bugfix和添加新功能入手 。事實上在公司參加一個新項目的開發或者維護也大多是從bugfix入手。這樣入手的好處在於可以集中精力去了解以小塊代碼的運作機制。顯然這很符合人的思維規律-做簡單的事情總比做複雜的事情來得容易和高效。當然這不是盲人摸象，要bugfix的話至少自己要知道整個軟件的功能和層次，這需要閲讀文檔而不是代碼。
說到註釋，這個時候就太有用了。不用說是別人寫的代碼，就是自己幾個月前寫的代碼自己也需要仔細看一下才能搞懂。但是殘酷的現實就是註釋很少，更殘酷的現實是越是低質量的代碼，它的註釋越是少。怎麼辦？只能猜 了。如果我們碰到一個很長的方法，但是我們需要跳過去看調它的代碼，我們就需要猜測這個方法的功能了。然後再回過頭來仔細看那個方法。我們可以運氣好的話作者會取很合理的class名，method名和變量名。其實裏面有個矛盾：很複雜，內聚很鬆散的method或者class，它們的名字就根本不可能取得合理。這個道理很簡單，一個method裏面做了很多事情，你就很難給它取一個合適的名字。像removeUserAndItsClientsAndUpdateTime()， 或者乾脆來個縮寫removeUCUpdateT()。 這樣的名字基本沒有可讀性。
還有就是讀上層 和讀下層 。讀上層就是在代碼的 高層閱讀，碰到底層的API可以猜出它的作用。這樣把一塊高層的代碼像讀邏輯那樣粗線條梳理清楚，其實就是一大塊一大塊地讀代碼。讀下層就是把底層的代碼if else一一讀懂。這兩者缺一不可。
碰到很亂的代碼幾乎只能利用IDE debug, step by step 得一行一行執行。因爲亂，所以沒有仔細看整體結構的必要，而最有效的就是step by step了。當然有些時候程序邏輯必須依賴數據庫或者外部數據，這樣的話光看代碼也不行。也只能step by step或者運行時log。
在OO的時代design pattern也已經深入人心。在看高質量代碼的時候會發現他們的代碼有個特點就是相當抽象，或者說面向抽象。裏面有很多interface, abstract class, 還有anonymous class, 很長的繼承鏈。我認爲既然作者寫程序的時候面向抽象，那麼我們讀程序的時候也要面向抽象 。我們經常在讀代碼察看某個變量的時後用IDE的查看功能點進去，然後發現它是一個接口全無實現。很多時候我們的第一反應就是找到具體的實現類，我倒是認爲可以關注這個接口先往下讀代碼，然後回過頭來看實現。既然作者的意圖就是讓接口來工作，我們就可以先了解作者的意圖來看代碼。順便說來，要讀懂很抽象的代碼，讀者自己首先要有很好的OO概念和design pattern的知識。
作者：盧聲遠<[email protected]>