程序員生存定律--如何儘快變的稍微專業一點

程序員生存定律這系列的目錄在這裏：程序員生存定律--目錄

喜歡從頭瞄的，能夠移步。

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

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（左側有二維碼）就好了。