英國作家奧斯卡·王爾德曾說過，人們給自己犯過的錯誤取名叫做經(jīng)驗(yàn)。因此可想而知，經(jīng)驗(yàn)不足的開發(fā)人員在編程道路上還有很多未曾踩過的坑。

在本文中，我會給你講講一些大多數(shù)開發(fā)人員都踩過的坑，希望對你有所啟發(fā)和幫助，以防止你也重蹈覆轍。

1、重新實(shí)現(xiàn)API中已有的代碼

大多數(shù)開發(fā)人員都會利用某種框架來減輕工作的負(fù)擔(dān)。對于沒有使用該框架經(jīng)驗(yàn)的開發(fā)人員來說，掌握框架的API提供的所有功能非常困難。

因此，他們常常會重新實(shí)現(xiàn)API中已有的某些代碼。沒有經(jīng)驗(yàn)的開發(fā)人員更有可能踩這個坑的原因有兩個。

第一，由于缺乏經(jīng)驗(yàn)，這些開發(fā)人員不了解API中有哪些開箱即用的功能。所以他們會白白浪費(fèi)時間來編寫框架中已有的代碼。由于缺乏經(jīng)驗(yàn)，所以他們無法充分地利用框架。

第二，缺乏經(jīng)驗(yàn)的開發(fā)人員不知道去哪兒找相應(yīng)的文檔。更有甚者，有人根本不看文檔。

對于沒有經(jīng)驗(yàn)的開發(fā)人員來說，這是一個大坑，因?yàn)橹匦聞?chuàng)建相同的功能似乎很誘人：有些函數(shù)只需重寫幾行代碼即可。另外，重寫這幾行代碼也不需要花費(fèi)太多時間。

但重寫相同的代碼有一定的弊端：造成代碼庫持有重復(fù)且未經(jīng)測試的代碼；由于新函數(shù)的引入，代碼會更加復(fù)雜；其他開發(fā)人員不熟悉這個函數(shù)，而且也不理解你為什么要引入這個函數(shù)。從整體來看，你的這一舉動增加了復(fù)雜性，卻沒有充分的理由。

2、簡單的問題不要復(fù)雜化

有時開發(fā)人員會遇到力所能及范圍之外的工作。問題在于經(jīng)驗(yàn)豐富的開發(fā)人員知道何時承認(rèn)這一點(diǎn)。有經(jīng)驗(yàn)的開發(fā)人員會設(shè)法盡量簡化工作，而沒有經(jīng)驗(yàn)的開發(fā)人員則很難把握火候，有時會做過頭。

其中一個原因在于，缺乏經(jīng)驗(yàn)的開發(fā)人員往往急于向團(tuán)隊的其他成員證明自己。他們會用各種奇怪的手段來實(shí)現(xiàn)代碼，比如古怪的單行小程式、過于復(fù)雜的抽象等。這會導(dǎo)致技術(shù)債務(wù)不必要地增加。

這種陷阱會加劇代碼的復(fù)雜度。實(shí)際上，我們應(yīng)該盡量保持簡單?！禞ava開發(fā)手冊（嵩山版）》推薦看下。經(jīng)驗(yàn)豐富的開發(fā)人員都會遵循KISS原則：Keep it simple, stupid（保持簡單和愚蠢）。

3、悄悄地吞掉錯誤

悄悄地吞掉錯誤是缺乏經(jīng)驗(yàn)的開發(fā)人員最常犯的一個錯誤。

有一次，一位相對缺乏經(jīng)驗(yàn)的開發(fā)人員在努力修復(fù)一個“查詢無效”的錯誤。該查詢會檢查產(chǎn)品是否仍有庫存，且會返回一個數(shù)值。

SELECT?*?FROM?Products?WHERE?amountInStock>?[數(shù)值]

這里會出Bug是因?yàn)閭鬟f給查詢的并非數(shù)值，而是一個空值。所以這個查詢看起來就像下面這樣：

SELECT?*?FROM?Products?WHERE?amountInStock>

這當(dāng)然會報錯。然而，這位缺乏經(jīng)驗(yàn)的開發(fā)人員“修復(fù)”了這個Bug，方法是將傳遞給查詢的變量轉(zhuǎn)換成了整數(shù)。雖然查詢的語法有效，但這并沒有解決問題。

這位缺乏經(jīng)驗(yàn)的開發(fā)人員沒有追查問題的根源，而是選擇在最底層“修復(fù)”Bug，當(dāng)然他們完全沒有惡意。

然而，正確地修復(fù)這個Bug的方法是，追查為什么會將NULL值傳遞給這個查詢，然后修復(fù)。引發(fā)這個問題的原因可能是由于提供有關(guān)庫存信息的API出了問題。如果是這種情況，那么可能根本不應(yīng)該執(zhí)行查詢。實(shí)際問題可能與查詢無法正常工作完全無關(guān)。

悄悄地吞掉這個錯誤，只會導(dǎo)致錯誤的真正原因被掩蓋。缺乏經(jīng)驗(yàn)的開發(fā)人員往往會從語法的角度來“修復(fù)Bug”，但這種做法會吞掉實(shí)際的錯誤。

4、過度自信

如果你問一個過度自信且缺乏經(jīng)驗(yàn)的開發(fā)人員，某個任務(wù)或用戶故事需要多長時間能做完，他會盡可能地告訴你一個最短的時間。如果你問過度自信的開發(fā)人員是否寫了測試，他會告訴你沒有必要。他會說他的代碼不可能有Bug，不可能出問題。

如果你覺得自己的第一份工作就無所不知，那么就大錯特錯了。如果你明明什么都不懂，卻沒有自知之明，那么才是真的可悲。這才是大多數(shù)缺乏經(jīng)驗(yàn)的開發(fā)人員身上最大的問題。

你要學(xué)會謙虛，虛心接受建設(shè)性的批評。從經(jīng)驗(yàn)豐富的開發(fā)人員那里獲取建議，這樣才有助于自身的成長。有信心是好事，但過猶不及。另外，Java 系列面試題和答案全部整理好了，微信搜索Java技術(shù)棧，在后臺發(fā)送：面試，可以在線閱讀。

5、僅測試正面測試用例

缺乏經(jīng)驗(yàn)的開發(fā)人員通常會專心交付功能或用戶故事。這就是所謂的快樂之路。然而，功能或用戶故事需要測試。經(jīng)驗(yàn)不足的開發(fā)人員和經(jīng)驗(yàn)豐富的開發(fā)人員在這點(diǎn)上有很大的分歧：沒有經(jīng)驗(yàn)的開發(fā)人員只會測試用戶應(yīng)有的操作，而經(jīng)驗(yàn)豐富的開發(fā)人員也會為邊緣案例編寫測試。

僅測試正面測試用例是很天真的做法。用戶具有不可預(yù)測性，而你需要測試的也不僅僅是正面測試用例。

6、換工具

擁有合適的工具，并熟練的掌握可以為你的日常工作節(jié)省大量時間。你應(yīng)該花一些時間找到合適的工具。在尋找工具時，你應(yīng)該選擇能夠?qū)崿F(xiàn)其承諾的工具。

如果你有合適的工具，那么就應(yīng)該堅持使用下去。不要每周都換工具。你需要一定的時間來了解并掌握這些工具。另外，Java 開發(fā)工具系列教程全部整理好了，微信搜索Java技術(shù)棧，在后臺發(fā)送：工具，可以在線閱讀。

另外，你還應(yīng)該潛心研究某個優(yōu)秀的IDE，因?yàn)槟愎ぷ鞯拇蟛糠謺r間都需要使用IDE。了解鍵盤快捷鍵以及如何使用代碼片段，并創(chuàng)建自己的代碼片段可以加快日常工作。

此外，你還應(yīng)該學(xué)習(xí)如何調(diào)試。選擇帶有某種調(diào)試器的IDE，可以方便你查看所有的變量值。這有助于你更好地掌握目前的情況，并為你節(jié)省大量的調(diào)試時間。

7、只注重技術(shù)，不關(guān)注業(yè)務(wù)

沒有經(jīng)驗(yàn)的開發(fā)人員還沒有掌握他們的技術(shù)棧，因此大多數(shù)人都傾向于專心學(xué)習(xí)技術(shù)棧，卻對業(yè)務(wù)視而不見。為了成為技術(shù)棧的大師，熟知業(yè)務(wù)非常重要。你需要明白為什么要構(gòu)建這些功能。

有些開發(fā)人員只對工作中的技術(shù)方面感興趣。他們不關(guān)心那些造就了自己所在崗位的商業(yè)或經(jīng)濟(jì)因素。

你究竟是在為企業(yè)創(chuàng)造價值，還是在一些無關(guān)緊要的事情上浪費(fèi)了太多時間？你需要搞清楚這個重要的問題。