程序員生存定律--成長路上常見的坑

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

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

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

前面講到了程序員成爲高手須要有一張地圖，藉助這樣一張地圖，程序員能夠嘗試成爲架構師、Guru或者純管理者。但這條路老是不會那麼順暢。

升級練功流的網文中總會給修仙的主人公設置下幾大關卡，好比：金丹難成、元神難成、成了元神後還有天人五衰等等。沒有這些關口，情節很難推進，因此仙俠類的網文幾乎無一例外依賴於這類設定。這一傳統甚至能夠追溯到《西遊記》和《封神演義》。

拿這個來對照程序員的增值道路，就會猛地發現，升級練功流也不徹底是扯淡。無論走那條道路，程序員的修煉路上一樣的也有三災九難，要想成就高手，仍是得一個個跨過去才行。若是一個程序員達到必定高度後再回頭觀望，那就會發現本身的同窗、曾經的同事老是會由於這樣那樣的緣由倒下去。這並非一個簡單的天道酬勤就能夠敷衍的行當，下面就讓咱們來具體看看，究竟增值過程當中可能遇到那些陷阱，掉到坑裏又須要付出多大代價才爬的出來。 

1． 學習失去焦點

軟件行業裏有幾個經典的題目，每過一段時間就會被翻出來PK一下，好比關於編程語言優劣的比較等。其中一個經典題目是軟件和數學的關係。

從結果來看，一派人認爲數學是軟件的基礎，而另外一派人認爲數學和軟件沒什麼太大關係，除非是在某幾個特定領域裏。若是你用心觀察過這事情，你就會發現這事情特別有意思。

好比說：

2011年，CSDN轉了一篇，叫：「數學是成就卓越開發人員的必備技能」的文章，在文末做者說：

那麼，數學對全部事都有利麼？這事情很難說，我對我如今的處境十分滿意，或許你也如此，但這都和潛能有關係。若是你是協做世界的一名開發人員，你真的不須要數學。若是你樂於你的整個職業生涯是這樣的：在工做時間中作企業CRUD應用，或在閒暇時間滑翔跳傘或極限水上滑板（或其餘各類時髦的極客運動），也分配較多時間在Spring、Hibernate、Visual Studio或其它東西上。那些特殊的職位並無真正限制你的潛力，你能變得極具價值，甚至可深刻追求。可是若是你想爲多樣化的職業生涯而奮鬥，想要有能力嘗試幾乎全部涉及代碼的事，從信息檢索到Linux內核。總之，若是你想成爲一個開發人員、程序員和計算機科學家的完美組合，你必須確保你的數學技能達到標準。長話短說，若是你在數學方面有必定天賦，那在軟件開發領域中全部的大門都是向你敞開的，若是沒有，那你就安安心心地作CRUD型工做吧！

總的來看，這個做者認爲數學很關鍵，得學。

而在2012年CSDN又轉了篇文章，叫：編程須要知道多少數學知識？在文章裏做者說：

數學和編程有一種容易讓人誤解的聯繫。許多人認爲在開始學習編程以前必須對數學很在行或者數學分數很高。但一我的爲了編程的話，須要學習多少數學呢？

實際上不須要不少。這篇文章中我會深刻探討編程中所須要的數學知識。你可能已經都知道了。

對於基本的編程，你須要知道下面的：

加減乘除—實際上，電腦會幫你做加減乘除運算。你僅須要知道何時運用它們。

模運算—模運算是用來計算餘數，它的符號一般用%百分號來表示。因此23除以7等於3，餘數是2。23 mod 7 = 2。

判斷是奇數仍是偶數的模運算—若是你想知道一個數是奇數仍是偶數，用它mod 2來做模運算。若是結果是0，它就是偶數。若是結果是1，就是奇數。23 mod 2等於1，因此23是奇數，24 mod 2等於0，24是偶數。

對一個數做百分數運算，就是用這個數來乘以一個百分數。譬如你要獲得279的54%，就是用0.54*279。這就意味着爲何1.0等於100%，0.0等於0%。

知道負數是什麼。負數乘以負數等於正數。負數乘以正數等於負數。就這麼簡單。

知道迪卡爾座標系統。在編程中，（0,0）表明屏幕左上角，Y座標的正軸往下。

知道勾股定律，由於它是用來計算笛卡爾座標中兩點之間的距離的。勾股定律a^2+^2=c^2。(x1,y1)和(x2,y2)兩點之間的距離等於((x1–x2)^2+(y1–y2)^2)。

知道十進制、二進制、十六進制。十進制就是咱們一般用的十個數：0-9。一般認爲這個十進制系統是人類發明的，由於咱們有十個手指。

 

總的來看，這個做者認爲數學不太關鍵，大多時候能夠不學。

你若是持續關注這事兒，各類極端對立的觀點絕對會吵爆你的頭。但這事情其實不可能有結論，由於被對立起來的兩極都是太大的概念。

好比說：若是把軟件開發縮減爲應用軟件的開發，那爭議性就會下降不少。

這裏的關鍵問題是，假如一我的的目標是應用軟件開發，卻花了10年來學習數學，接下來在實際應用程序開發過程當中，天天面對的是UI佈局、IDE使用、圈複雜度控制、面向對象使用、設計模式的使用和類庫的使用這類問題，那麼這我的就會發現數學其實沒啥用，他等價於由於失去焦點而失去了10年。

這裏想代表的是，一旦誤讀了知識與目的間的因果關係，那麼學習就會失去焦點，進而形成負效應，畢竟相對於人的可承受負荷而言，這個世界上的知識不是太少，而是太多。

通常的認識是隻要學習就必然有所得，因此對人生的影響必定的是正面的。但實際上這個想法是偏頗的，尤爲是在軟件行業裏。

在軟件行業中，這種風險之因此異常突出，就在於前面提到過的軟件的兩個特質：更迭速度快和子領域衆多。這兩個因素致使軟件相關的知識是爆炸性增加。

而避免「失去焦點」這一陷阱的第一關鍵則是分類：對軟件開發進行分類，對軟件所關聯的知識也進行分類，造成本身的大局觀和總體視圖。

前文曾經提過集中對知識進行分類，對軟件進行分類的方法，這裏再補充一個對繞過這一陷阱有幫助的分類方法，它來自《軟件成本估算：COCOMOII模型方法》這本書。

書裏面把軟件分紅了下面幾個類別：

終端用戶編程（通常的應用程序）
應用程序生成器（開發工具等）	應用組裝	系統集成
基礎結構（OS，DB等）

 

在進行分類的同時，書裏還給出了一組數據，即95%的人從事的是終端用戶編程。

這個分類的意義在於，經過它咱們能夠認識到每一類別背後隱含的知識需求其實不同，程序員則要根據本身的目的設定焦點。再來看一個具體的例子：

算法領域中，最經典的書籍恐怕是Donald Knuth的《計算機程序設計藝術》。對此書的評價已經不止是高那麼簡單了，如：

這部多卷專著是公認的對經典計算機科學最權威的描述。幾十年來，不管是學生、研究人員仍是編程從業人員，本套書的前三卷都是他們學習編程理論、進行編程實踐的寶貴資源。 

這是一套集全部基礎算法之大成的經典之做，當今軟件開發人員所掌握的絕大多數計算機程序設計的知識都來源於此。 

---Byte

那麼是否是每一個人都應該把這書讀一讀？這書的前三卷大體有2000頁，上班的人都讀通估計要1~2年這個樣子。

至少在我來看，答案是否認的。具體狀況要看你作的是那類軟件，你人生的下一步在那裏而定。

假設說一我的作的是終端用戶編程（好比：財務類軟件），而且目標也是在這個方向上繼續深造，那麼你讀這書實際上是在浪費時間。

這是由於在終端用戶編程上，本身去寫算法的機會很是的少，甚至可能沒有。反卻是業務領域知識（會計知識）、OO、設計模式、甚至於估算這些知識都比研究算法更有價值。 既然如此，那麼從務實的觀點上看，爲何去學習不能在可見範圍內創生價值的東西，而不是去學習馬上能夠變現的東西。走極端的人會找出須要寫算法的例子來反駁上述立論，但點不足以表徵面，即便偶爾須要本身瞭解下算法，真就值得花那麼多時間去學習麼，爲何不盡量借鑑現成的。

而在基礎結構性的軟件開發中，情形就不一樣，這時算法無疑是很是核心的東西。因此Google這類公司的面試中每每很是強調算法。

這裏最關鍵的就是聚焦，聚焦的根本則是要在限定時間範圍內創生價值。

從方法上講，聚焦就是找到一個適合本身大小的區域，而後作深。才華橫溢的不論，通常來說，橫向穿越和縱向穿越都不太行，除非已經基本窮盡當前的領域。縱向穿越是指從底層穿到上層（想一想開發網絡協議的和用網絡協議的），橫向穿越則指橫跨太多的領域（想一想從內核驅動跨越到信息管理軟件）。

其實若是一我的真的擁有無限的時間資源，那麼什麼時間點學習什麼就變得不太關鍵。但這是不可能的，同時一我的的學習時間遠不像想的那麼充沛。這點會在後面探討。 

在清楚本身的目標後，再配合前面提到的知識分類地圖，那麼避開這一陷阱的概率就大了不少。

2． 學習與實踐相分離

喜歡看網文的不多有人會不知道起點，不過估計不多有人注意過起點給小說分類的標籤。在網文小說裏有不少個流派，其中一個叫作「扮豬吃虎」。這個流派的基本特徵是很厲害的一我的要僞裝很菜，最後在關鍵時刻力挽狂瀾。這個流派十分有人氣，大概僅次於「升級練功」，而遠高於「重生」、「轉世」這類的流派。

網文是絕對的市場導向，因此這個現象能夠從側面說明不少人喜歡「扮豬吃虎」或者說潛意識裏有着「扮豬吃虎」的情節。「扮豬吃虎」這事兒小說裏看着很爽，但挪到現實裏來很容易讓人掉到學習陷阱裏。更可怕的是，現實裏有這種心思的人其實也還不少。

有時候會看到這樣一種現象：不少人自學的東西和工做中用的東西徹底不要緊。好比：一邊用着C#作Web開發，一邊本身學習着C/C++作嵌入式。

這事並不必定不對，只能說很是危險，極可能會致使那樣都沒有高度。咱們得認可當人生被錯位的時候，每每只能這樣來改變命運，這是沒辦法，也是正確的。但首先要認識到這樣作是至關低效的，低效到必定程度後對的事情也並不必定有結果。

CSDN曾經作過一份薪酬統計（http://www.programmer.com.cn/5877/），這裏面有三個與上述身在曹營心在漢現象有關聯的結論：

一是73%的程序員對本身的薪資並不滿意。

二是各個主流開發語言上的差別並無想的那麼大。雖然C#開發者中月收入小於5000元的比例最高，但5000~10000這個羣體在主流開發語言上相差並不大。

三是平均來看，收入增加和工做年限正相關。固然認爲到那個歲數工資天然就高了是很危險的。

對薪資不滿意應該是程序員但願跨界的一個原動力，但收入和年限正相關，與語言非正相關卻說明單純從功利角度看跨界並不明智。由於假設一我的Java語言用過三年，C#用過三年，總的來看收入水平更可能處在三年的水平上，而不是六年的水平上。

軟件是一種固化的思惟，這就軟件開發更可能是一種實踐而非是一種理論。軟件開發內的不少領域，整體上看體現的是複雜而不是艱難，不管是前端開發仍是驅動開發。

講到到這裏就有必要簡單區分一下「複雜」和「艱難」。考試出題能夠有兩種方法：一是每道題都不是很難，但題量很大；一是題量不多，但每道很難。從結果來看，兩類考試方法下，得高分都並不容易，但其難度的來源卻並不相同，前者更多的體現爲複雜，然後者卻體現爲艱難。

在軟件行業裏，除了一些專門的領域，好比圖像算法等，軟件開發則更相似於前者，因此通過培訓後大部分人均可以作軟件開發，進入門檻並不高。

解決艱難問題時，天分很重要；解決複雜問題時，練習很重要。因此軟件開發的學習過程當中，實踐很重要，純理論知識的權重較低，固然基本的算法複雜度仍是要明白的。

這也就意味着脫離項目實踐的學習投入產出比每每會差。好比說：編程中常見的多線程問題。若是單純從學習的角度看，建立線程自己並不複雜，掌握各類線程同步方法（事件、信號燈、互斥量等）也並不複雜。寫簡單例子的時候，也不多會出錯。但一旦落到具體的場景下，雖然多線程的本質沒變，但沒經驗的人幾乎必定會在涉及多線程的代碼上致使一下子出，一下子不出的問題。

再好比說：你可能看了不少設計的書，但歷來沒有從頭至尾寫過什麼程序，老是在既有代碼上修修改改，或者只是完成幾千行代碼的小工具，那麼你的設計知識是很難融匯貫通的，也仍是沒法很好的承擔大系統的設計工做。

這點上有一個旁證，根據統計最多的Bug是由新手致使的。這從側面說明，能作和能作好之間的鴻溝須要大量的實踐來填平的。

在這樣一種前提下，指望先選個工做，再本身學習，努力轉行這樣的想法是損失很大的。單純從增值效能上看，解決這點很簡單，除非必須放棄當前的工做領域，不然要以當前參加的項目爲根基展開學習，這樣才能比較好的調和學習和實踐。

而除非一個工做領域過於偏狹，大多時候在編程語言（C#→C/C++）、不一樣領域間（圖形處理→地理信息系統等）穿越損失可能更大。

至於如何在「博」與「專」間平衡，如何選中更適合本身的工做領域，將在後續章節裏陸續談到。

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

關於我本身的各類信息，在左邊欄可找到，想了解下寫這系列文章的人是否是騙子和大忽悠的能夠瞄。

最後但願感興趣的支持V衆投，感受上這應該是國內最靠譜的生活購物等的問答社區了吧，都是朋友給朋友作的答案，同時實行一人一號，一人一票制度，想找什麼答案關注公衆號：vzhongtou（左側有二維碼）就好了。