其實，作為一個程式設計師，在成長的過程中，肯定是踩坑無數的。要說學習中的誤區，那肯定是相當的多的，不過在說學習誤區之前，我們可以先說一個程式設計師對於習慣上的誤區。

那就是，非常非常多的程式設計師對於自己的東西都是十分自信的，我們會聽到程式設計師說一句話：“啥bug？不可能啊，我測試的時候都沒有。”然後自己點了點，發現確實有這個bug。這樣的事情非常的多見，有時候，這種盲目的自信就會讓自己範很多的錯誤。

我一個朋友，做一個系統時，我發現了他潛在的一些風險，然後告訴了他。他非常自信的告訴我：“你做可能會出這樣的問題，但是我不會。”我回敬他的只能是白眼。

後來，他確實遇到了問題，和我當時預計的一樣。當他來找我求助時，我懟了他一句，“早知如此，何必當初。”他回答我，“雖然你給我說了屎難吃，但是我不試一下，怎麼知道是真的呢？”

所以，作為一個程式設計師，首先應該學習的就是，不要那麼盲目的自信，對於問題，要有更多的思考。

廢話說了一段，我們進入正題，程式設計師學習中有哪些誤區呢？

作為一個程式設計師，實踐和理論其實應該是並重的。我們需要將理論轉化為實踐，也需要在實踐中探索和印證理論。

但是很多時候，一些程式設計師會有多多少少的偏科。

對於動手能力強但是靜不下來的程式設計師，他們會更多的喜歡實踐，但是不喜歡理論。畢竟，理論是比較枯燥的，也因為如此，在很多時候，即使經驗豐富的程式設計師，面試時也會出現答非所問的情況，這就是一個重實踐輕理論的典型。

當然，也有人正好相反，喜歡看書，逛各種的部落格和社群，學習了很多理論的知識，但是看了，記住了，並不自己動手去試一下，因此，雖然理論知識很充足，但是動手能力很差，無法將理論轉化為實際的生產力。

因此，如果我們想成為一個優秀的程式設計師，理論和實踐一定需要並重的，要知其然知其所以然，還要能夠用於實際的專案中。

很多程式設計師，可能社交的能力不是很強，因此，遇到問題，第一個想到的就是百度、Google，從來不會把“請教一下身邊的人”作為備選項。

其實，這種方式是不對的。很多時候，我們是需要靠自己，畢竟學習是自己的事情。有些問題確實問別人的話，可能會被吐槽一下“這麼簡單都不懂？”但是，你只需要花費幾分鐘的時間，可能就能夠搞明白，然後在自己去看資料深入。這比一個人漫無目的的去找尋解決方案，效率不知道高了多少倍。

當然，還有另一種極端，就是，自己不願意思考，遇到問題就問人。

這也不是一種學習的態度，因為雖然這次你得到答案了，但是並沒有有效的去記憶並且思考原理，只是單純的完成任務而已。

因此，正確的學習方法，有問題，簡單的自己思考解決，要是15分鐘了，自己還沒有頭緒，那麼就請教一下，找到解決方案一下，再花一些時間，瞭解一下為什麼要這樣做，還有沒有其他解決方案。

在現在這個飛速發展的時代，只是單一的有技術的深度已經遠遠不夠了。我們還需要技術的廣度。

很多程式設計師可能只是一門心思的專研一種技術，對於其他技術嗤之以鼻。這是一個相當大的誤區。語言或者技術，本來就是用來解決問題的，沒有好壞之分，我們需要了解儘量多的技術，這樣，在技術選型的時候，可以分析專案的特點選擇合適的技術。

技術本身，也是一種成本的投入，我們不需要用最好的技術，只需要用最適合的技術，所以，什麼技術都需要了解一下的。

對於程式設計師的工作來說，英語確實不是必須的，函式也就幾十個，記住了，會用，基本上平時的工作就都沒有問題了。

不過，我們平時會有非常非常多的一些新興的技術出現，而這些技術大多都來自國外，因此，我們在看國內的很多資料時，很多時候都是隻言片語，可能百度翻遍了，也搞不懂原理。

這個時候，我們就需要看看英文書了，或者一些英文的資料，這種，能夠非常有效的讓我們瞭解其中的原理。

程式設計師在學習的時候，其實非常容易出現這種狀態，就是，我好想什麼都懂了，不知道應該學什麼呢？

如果出現這個狀態，那麼說明，你懂的太少了。坐井觀天的成語大家都應該聽過，青蛙覺得天只有井口那麼大，是因為他只看到了那麼大的天。而學習也是一樣的，當你覺得自己什麼都懂的時候，那說明，你的眼界太窄了。

人生，就是一邊踩“坑”，一邊上升的過程。而程式設計師的一生，不僅要改無數的BUG，也要越過很多的“坑”。今天，下面為大家分享一些開發人員常見的“坑”，希望同學們能夠從中受益。

1、重新實現API中已有的程式碼

大多數開發人員都會利用某種框架來減輕工作的負擔。對於沒有使用該框架經驗的開發人員來說，掌握框架的API提供的所有功能非常困難。

因此，他們常常會重新實現API中已有的某些程式碼。沒有經驗的開發人員更有可能踩這個坑的原因有兩個：

第一，由於缺乏經驗，這些開發人員不瞭解API中有哪些開箱即用的功能。所以他們會白白浪費時間來編寫框架中已有的程式碼。由於缺乏經驗，所以他們無法充分地利用框架。

第二，缺乏經驗的開發人員不知道去哪兒找相應的文件。更有甚者，有人根本不看文件。

對於沒有經驗的開發人員來說，這是一個陷阱，因為重新建立相同的功能似乎很誘人。有些函式只需重寫幾行程式碼即可。

另外，重寫這幾行程式碼也不需要花費太多時間。但重寫相同的程式碼有一定的弊端：造成程式碼庫持有重複且未經測試的程式碼；由於新函式的引入，程式碼會更加複雜。

其他開發人員不熟悉這個函式，而且也不理解你為什麼要引入這個函式。從整體來看，你的這一舉動增加了複雜性，卻沒有充分的理由。

2、簡單的問題不要複雜化

有時開發人員會遇到力所能及範圍之外的工作。問題在於經驗豐富的開發人員知道何時承認這一點。

有經驗的開發人員會想方設法的儘量簡化工作，而沒有經驗的開發人員則會將簡單的問題複雜化，複雜的問題更加複雜化。

實際上，我們應該儘量保持簡單。增加技術債務只會降低程式碼的可閱讀性，增加維護的難度。

3、過度自信

如果你問一個過度自信但是缺乏經驗的開發人員，某個需求需要多長時間能做完，他會盡可能地告訴你一個最短的時間。

如果你問過度自信的開發人員是否寫了測試，他會告訴你沒有必要。他會說他的程式碼不可能有bug，不可能出問題。

如果你覺得自己的第一份工作就無所不知，那麼就大錯特錯了。如果你明明什麼都不懂，卻沒有自知之明，那麼才是真的可悲。這才是大多數缺乏經驗的開發人員身上最大的問題。

所以，作為開發人員，一定要學會謙虛，虛心接受前輩或者別人的建議和意見。從經驗豐富的開發人員那裡獲取建議，這樣才有助於自身的成長。有信心是好事，但過猶不及。

4、僅測試正面測試用例

缺乏經驗的開發人員通常會專心交付功能或需求。這就是所謂的快樂之路。

然而，功能或需求需要測試。經驗不足的開發人員和經驗豐富的開發人員在這點上有很大的分歧：沒有經驗的開發人員只會測試使用者應有的操作，而經驗豐富的開發人員也會為邊緣案例編寫測試。

僅測試正面測試用例是很天真的做法。使用者具有太大的不可預測性，而你需要測試的也不僅僅是正面測試用例。

5、頻繁更換工具

擁有合適的工具，並熟練的掌握可以為你的日常工作節省大量時間。你應該花一些時間找到合適的工具。在尋找工具時，你應該選擇能夠實現其承諾的工具。

如果你有合適的工具，那麼就應該堅持使用下去。不要每週都換工具。你需要一定的時間來了解並掌握這些工具。

另外，你還應該潛心研究某個優秀的IDE，因為你工作的大部分時間都需要使用IDE。瞭解鍵盤快捷鍵以及如何使用程式碼片段，並建立自己的程式碼片段可以加快日常工作。

6、只注重技術，不關注業務

沒有經驗的開發人員還沒有掌握他們的技術棧，因此大多數人都傾向於專心學習技術棧，卻對業務視而不見。為了成為技術棧的大師，熟知業務非常重要。你需要明白為什麼要構建這些功能。

有些開發人員只對工作中的技術方面感興趣。他們不關心那些造就了自己所在崗位的商業或經濟因素。

說到底，作為開發人員一定要謹記，我們是在為企業創造價值，而業務能否成交將直接影響企業最終收益，企業最終收益將直接關係到每個人的價值和收益。所以，作為開發人員，既要注重技術，也要關注業務層面。