程序員生存定律這系列的目錄在這里：程序員生存定律--目錄
喜歡從頭瞄的，可以移步。
------------------------------------------------------------------------------
1 掌握讀代碼的方法和技巧
不管最終想成為什么，剛入行之后，一定離不開的是讀代碼和寫代碼。這里將介紹一些讀代碼的方法和技巧。
讀代碼這事，先要分是精讀還是泛讀。從學習的目的來看，一定要精讀一定量的經典代碼。而精讀是指每行都讀懂，不看代碼腦子里就能勾畫出程序的基本結構。
要想判斷是不是精讀了有個很形象的判斷方法：精讀代碼時會滿腦子都是代碼，放不下，甚至睡覺前腦子里也是代碼。達到這個程度就是精讀了，否則應該就還不是。精讀代碼要控制規模（初始階段一萬行以下即可）並用心，不太需要什么特別的方法。
這節里主要關注的是如何泛讀較大規模代碼，不是精讀。
現存的很多系統往往很大，幾十萬行的可能也只算普通。這時候一旦加入了這樣一個項目，應該如何去讀代碼？
讀規模較大的程序前，先得把規格說明書大致弄清楚，而不能上來就讀。比如：對於應用程序，要先大致整清楚它的使用方法、使用場景；對於庫則要弄清楚它對外接口的定義。
如果其中有涉及到某些專門的領域知識，比如：流程、財會等，那也最好預先有些認識。這類東西徹底的從代碼里反推回來是不太可能的。如果弄不清這類東西，很多時候對讀程序是個很大的障礙。你不知道代碼做的是什么，卻去讀對應的程序，那就只能看到調用來調用去，最終會雲里霧里。
接下來從大往小，從面到點來看。
一旦開始接觸代碼，那要先弄清楚代碼的基本靜態結構。如：包構成、類構成等。這里幾乎一定會涉及一個層次問題。一下子把層次探的太深，就容易盯在細節上出不來。把層次拔得太高，又容易流於表面。從數目上看，一個層次最好不要超過10個關鍵概念，超過了真記不住。在靜態結構這步，要弄清楚每個部分的核心職責，可以是很簡單的概括，最好能記住。
接下來選擇出最常用的典型場景，然后在典型場景下考察上面的靜態結構是如何發揮作用的。典型場景下用到的接口往往就是關鍵的接口，要弄清楚他們的定義和作用。也要整清楚典型場景下數據流的變遷。
通過這兩個步驟等價於腦子里可以生成一份比較高層次的靜態和動態結構圖，很像UML里的Sequence圖和類圖。牽涉到數據庫的時候，一般需要對相應的數據規格有所了解。
接下來要關注進程、線程的結構。比如：都是什么時候開始、什么時候結束的，在上述典型場景下都負責干什么。
上述四步（規格、靜態結構、典型場景、進程線程）完成后，對程序的第一次泛讀完成。檢驗是否達成目標的方法可以很簡單，如果真的基本讀懂了，這時應該能夠單靠紙筆描述出程序典型場景的Sequence圖。
做第一次泛讀的時候，要抑制自己的求知欲，因為總是很想在調試器里通過call stack把一個功能的實現細節整清楚。至少在第一個次泛讀里，可以先不要這樣。
第一次泛讀后，就要進入深掘的過程，一般來講需要針對自己會負責的部分進行深入挖掘。這部分功能往往會隱藏在某個接口之下。
這時候一般來講可以把功能型的模塊優先級降低，比如：XML解析的模塊等。其他部分可以認為是需要把之前所說的四個步驟再重復一下。但這時候要關注細節和調用堆棧了。
不管是在那個讀代碼的層次，有兩個基本技巧總是需要的，一個是要掌握具體程序里內嵌的Log機制，要能看Log，必要時可能還得加Log；一個是基本調試方法。同時一個合適的代碼閱讀工具會對提升代碼閱讀速度有所幫助，比如：一款名叫SourceInsight的小工具中可以把窗口分拆為幾個部分，點擊任何方法的時候，這個方法的實現以及Calls Graph都可以被自動展開，這樣的小功能無疑的對閱讀代碼是有幫助的。
2 從那門編程語言開始學習好些？
學習編程至少要掌握一門編程語言，但從那門編程語言開始是一個極其容易引起爭議的問題。為使結論經得起推敲，這里需要做一點系統的分析。
純從未來應用的角度看，結果是不確定的，在學習的時候，其實沒人能夠知道未來會主要使用那門語言。因為最終工作中使用那門編程語言往往取決於一些很偶然的因素，比如現有產品的開發語言，待解決問題的領域等。比如說如果命運安排你去做和Hadoop相關的工作，那很可能會用到Java，如果安排你去做驅動開發，那就很可能會用到C/C++。
如果上述這點成立，並且被預設為前提，那么在學習階段應該學什么就可以有個相對確定的答案：學習階段學習語言的目的是為了掌握編程的基礎概念並能更快速的學好另一門語言。顯然這仍然是打基礎的范疇。
從這個角度看，只有一門語言是必須學的，那就是C。因為不了解這門語言會造成一定視野上的限制，使基礎薄弱，比如不掌握C語言的人，很可能無法了解《深入理解計算機系統》這樣的書，進一步也就不理解什么是指針，什么Stack，什么是Stack Overflow，什么是寫超界，做性能優化的時候可能也就想不到一些系統級的手段。Joel在《軟件隨想錄》里專門有一章叫“學校只教Java的危險性”，其中所表達的觀點與這里的觀點類似。
作為結果，盡管很可能在工作中用不上C語言，在學習的時候還是要把它掌握，除非在最初階段就已經下定決心只把技術當做敲門磚，而不想走的更遠。要不然根基就過於薄弱了。
至於其他一些比較主流的語言比如C++，Java，C#等可以完全按照興趣來進行選擇，唯一關鍵的是不管選擇那個都要累積一定代碼量並把它學透。這樣依此擴展到將來要用的編程語言，學習曲線往往就會很平，大致2~3周就可以用新的語言做一些基本的開發工作。
選擇編程語言的另一種思路是從腳本語言入手，比如PHP，Python，Javascript等。這就和趙匡胤當年要下決策是先搞定弱的南唐還是先搞定強的遼國一樣，是個兩難的話題。從入手容易，培養興趣的角度看，顯然腳本更好些，並且腳本語言也是互聯網的顯學，未來用到的機會很高；但如果想多積累，厚積薄發那么就還是從C入手會好些。我個人的建議是如果在大學里那就先難后易好些，因為人生里不總是有這么大塊的時間；但如果是后想轉入這個行業，那就直接找腳本開始吧。
3 小結
寫程序、讀程序、學好學習曲線陡的知識、避免IDE依賴這些事情的根本目的都是為了打好基礎。這個環節里最忌諱的是急功近利，比如：學習一堆IDE的操作方法、每個編程語言都掌握一點。很多人可能誤以為這對找工作有幫助，所以把但凡接觸過的技術都列到簡歷里是很常見的做法。但其實這個認識是不對的，但凡有點規模的公司招聘畢業生或者剛畢業不久的開發人員的時候都更看重他的基礎和發展潛力。而基礎和潛力這兩樣東西很難精確度量，但並不難判斷，通過簡單的面試既可以判斷出來。只關注當下這個人能干什么的公司很可能是看不到明天的公司。
------------------------------------------------------------------------------
關於我自己的各種信息，在左邊欄可找到，想了解下寫這系列文章的人是不是騙子和大忽悠的可以瞄。
最后希望感興趣的支持V眾投，感覺上這應該是國內最靠譜的生活購物等的問答社區了吧，都是朋友給朋友做的答案，同時實行一人一號，一人一票制度，想找什么答案關注公眾號：vzhongtou（左側有二維碼）就行了。