程式員怎麼樣生存

程式員生存定律這系列的目錄在這裡：

喜歡從頭瞄的，可以移步。

-------------------------------------------------------------------------------

1 掌握讀代碼的方法和技巧

不管最終想成為什麼，剛入行之後，一定離不開的是讀代碼和寫代碼。這裡將介紹一些讀代碼的方法和技巧。

讀代碼這事，先要分是精讀還是泛讀。從學習的目的來看，一定要精讀一定量的經典代碼。而精讀是指每行都讀懂，不看代碼腦子裡就能勾畫出程式的基本結構。

要想判斷是不是精讀了有個很形象的判斷方法：精讀代碼時會滿腦子都是代碼，放不下，甚至睡覺前腦子裡也是代碼。達到這個程度就是精讀了，否則應該就還不是。精讀代碼要控制規模（初始階段一萬行以下即可）並用心，不太需要什麼特別的方法。

這節裡主要關注的是如何泛讀較大規模代碼，不是精讀。

現存的很多系統往往很大，幾十萬行的可能也只算普通。這時候一旦加入了這樣一個項目，應該如何去讀代碼。 

讀規模較大的程式前，先得把規格說明書大致弄清楚，而不能上來就讀。比如：對於應用程式，要先大致整清楚它的使用方法、使用情境；對於庫則要弄清楚它對外介面的定義。 

如果其中有涉及到某些專門的領域知識，比如：流程、財會等，那也最好預先有些認識。這類東西徹底的從代碼裡反推回來是不太可能的。如果弄不清這類東西，很多時候對讀程式是個很大的障礙。你不知道代碼做的是什麼，卻去讀對應的程式，那就只能看到調用來調用去，最終會雲裡霧裡。

接下來從大往小，從面到點來看。

一旦開始接觸代碼，那要先弄清楚代碼的基本靜態結構。如：包構成、類構成等。這裡幾乎一定會涉及一個層次問題。一下子把層次探的太深，就容易盯在細節上出不來。把層次拔得太高，又容易流於表面。從數目上看，一個層次最好不要超過10個關鍵概念，超過了真記不住。在靜態結構這步，要弄清楚每個部分的核心職責，可以是很簡單的概括，最好能記住。 

接下來選擇出最常用的典型情境，然後在典型情境下考察上面的靜態結構是如何發揮作用的。典型情境下用到的介面往往就是關鍵的介面，要弄清楚他們的定義和作用。也要整清楚典型情境下資料流的變遷。

通過這兩個步驟等價於腦子裡可以產生一份比較高層次的靜態和動態結構圖，很像UML裡的Sequence圖和類圖。牽涉到資料庫的時候，一般需要對相應的資料規格有所瞭解。

接下來要關注進程、線程的結構。比如：都是什麼時候開始、什麼時候結束的，在上述典型情境下都負責幹什麼。

 上述四步（規格、靜態結構、典型情境、進程線程）完成後，對程式的第一次泛讀完成。檢驗是否達成目標的方法可以很簡單，如果真的基本讀懂了，這時應該能夠單靠紙筆描述出程式典型情境的Sequence圖。

做第一次泛讀的時候，要抑制自己的求知慾，因為總是很想在調試器裡通過call stack把一個功能的實現細節整清楚。至少在第一個次泛讀裡，可以先不要這樣。

第一次泛讀後，就要進入深掘的過程，一般來講需要針對自己會負責的部分進行深入挖掘。這部分功能往往會隱藏在某個介面之下。

這時候一般來講可以把功能型的模組優先順序降低，比如：XML解析的模組等。其他部分可以認為是需要把之前所說的四個步驟再重複一下。但這時候要關注細節和呼叫堆疊了。

不管是在那個讀代碼的層次，有兩個基本技巧總是需要的，一個是要掌握具體程式裡內嵌的Log機制，要能看Log，必要時可能還得加Log；一個是基本調試方法。同時一個合適的代碼閱讀工具會對提升代碼閱讀速度有所協助，比如：一款名叫SourceInsight的小工具中可以把視窗分拆為幾個部分，點擊任何方法的時候，這個方法的實現以及Calls Graph都可以被自動延伸，這樣的小功能無疑的對閱讀代碼是有協助的。

http://www.dianping.com/shop/6827152