建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)
創(chuàng)新互聯(lián)公司于2013年創(chuàng)立，先為海原等服務(wù)建站，海原等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為海原企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
賈科莫·卡薩諾瓦說：“不犯錯的人一事無成?！睕]有人能從不犯錯，尤其是在軟件開發(fā)這一“艱難”的領(lǐng)域。有的錯誤嚴(yán)重些，有的錯誤沒有那么大的影響力。錯誤是始終存在的。
無需為犯錯而擔(dān)憂，事實(shí)上，犯錯使我們成長。以下一些錯誤是很典型的問題，幾乎每個人都經(jīng)歷過，從中吸取經(jīng)驗(yàn)，在通往優(yōu)秀開發(fā)人員的道路又進(jìn)一步。
假如你沒有，那么請從別人的錯誤中學(xué)習(xí)。人生中沒有如此多的時間來一一經(jīng)歷所有的錯誤。
1. 快速而凌亂
大多數(shù)開發(fā)人員在職業(yè)生涯中都曾用快速而凌亂的方案來解決問題。這種方法存在一些嚴(yán)重的缺陷，從而導(dǎo)致更多的技術(shù)債務(wù)。最重要的是，快速而凌亂的解決方案可能會破壞團(tuán)隊(duì)的士氣。
也許在某些事例中，快速而凌亂可能無傷大雅。如在代碼壽命短的某些情況下，這實(shí)際上可能是正確的方法。但需要長期運(yùn)行代碼時，修復(fù)快速又凌亂的工作會反咬你一口。
2. 編寫過于花哨的代碼
尤其對于沒有足夠經(jīng)驗(yàn)的開發(fā)人員來說，在其編碼生涯中都有一段時期，試圖尋求其他開發(fā)人員的認(rèn)可。
不要花太多時間編寫最完美的代碼。按照既定目標(biāo)編寫代碼并使其按預(yù)期工作。這樣做會給自己留出很多額外的時間，從而可以創(chuàng)造更多價(jià)值。
3. 在錯誤的分支中提交代碼
該錯誤列表從一個小錯誤開始——只要及時發(fā)現(xiàn)就不會產(chǎn)生重大影響。盡管開發(fā)人員可能會浪費(fèi)大量時間來修復(fù)此錯誤。
在錯誤的分支中提交代碼，這種事情開發(fā)員們做過不止一次。如果及時發(fā)現(xiàn)，則可以輕松解決問題。當(dāng)開始在錯誤的分支中提交代碼時，事情就變得棘手了。 4. 低估工作量
“這很簡單嘛?！?/p>
事實(shí)證明事情并沒有想象的那么容易。嘗試的第一個解決方案并未達(dá)到預(yù)期的效果。而最后為了修復(fù)第一次未解決的問題采取的另一種方法會花費(fèi)更多時間。
低估工作量是一個經(jīng)常發(fā)生的典型錯誤。尤其是當(dāng)團(tuán)隊(duì)使用諸如Scrum之類的敏捷方法時，這種錯誤常有發(fā)生。
確保自己不僅要計(jì)算開發(fā)人員的時間，還需要一些時間來做其他事情，比如測試。
5. 沒有提交正確的文件
筆者經(jīng)?？吹秸_的文件沒有提交到存儲庫。這里有兩種情況：要么提交的文件過多，要么提交的文件出現(xiàn)遺漏。
有時提交了太多文件。筆者已經(jīng)見過IDE文件最終存儲在存儲庫中無數(shù)次了。這主要是因?yàn)殚_發(fā)人員工作馬虎。盲目地將所有文件添加到提交中通常并無益處。
缺少yarn.lock文件是文件在提交中出現(xiàn)遺漏的典型例子。在大多數(shù)情況下，這與知識缺乏或理解不足有關(guān)。開發(fā)人員不知道文件的用途，因此害怕將其添加到存儲庫中?；蛘咚麄兛赡苷J(rèn)為該文件僅適用于其本地環(huán)境。
盡管這種情況取決于丟失的文件，但在大多數(shù)情況下，此錯誤會導(dǎo)致文件破壞。如果缺少yarn.lock，開發(fā)人員將在所有環(huán)境中獲得不同版本的依賴關(guān)系。這可能會導(dǎo)致一些令人困擾的錯誤。
6. 由于缺乏相關(guān)知識而做無用功
大多數(shù)開發(fā)人員使用某種框架來簡化生活。如果一個開發(fā)人員正在學(xué)習(xí)框架，可能很難知道框架API中的所有可用內(nèi)容。
典型錯誤是開發(fā)人員不知道框架中已有的功能。由于缺乏相關(guān)知識，開發(fā)人員實(shí)施了與框架中現(xiàn)有方法幾乎相同的新方法。
這導(dǎo)致時間被浪費(fèi)在生產(chǎn)框架中已經(jīng)存在的代碼。缺乏經(jīng)驗(yàn)還使開發(fā)人員無法充分挖掘框架潛力。
7. 自認(rèn)為不需要測試代碼
“這段代碼很簡短，不會影響到任何重要的事情。”
每個開發(fā)人員都編寫過簡短的代碼，你以為它們不會破壞任何主要內(nèi)容，實(shí)則不然，添加的兩行代碼成功打破了無法預(yù)料的內(nèi)容。
測試代碼確實(shí)是個不招人喜歡的活兒。有些人沒有理解測試代碼的目的，認(rèn)為這是浪費(fèi)時間，常常不切實(shí)際。
怎么才知道自己的代碼能正常運(yùn)行呢?請讓一些真實(shí)的測試支持自己的話。全面的測試可以過濾出關(guān)鍵的錯誤，從而確保代碼按預(yù)期方式運(yùn)行。 8. 缺乏練習(xí)
大家都知道熟能生巧的道理。因此，為擴(kuò)展技能，便需要更多的練習(xí)。不學(xué)習(xí)新事物是開發(fā)人員可能犯的最大錯誤之一。
如果想學(xué)習(xí)一種新技術(shù)或編程語言，開發(fā)人員可能不得不在日常工作之外進(jìn)行學(xué)習(xí)。為了不落伍，這是必須對自己進(jìn)行的一項(xiàng)投資。
9. 過于自信
當(dāng)然，擁有信心是一件很棒的事情——但只在一定程度上。開發(fā)人員過于自信時，就很難聽得進(jìn)去別人的意見了。
過于自信的開發(fā)人員完全認(rèn)識不到自己也會犯錯誤的事實(shí)，因此他們往往在不咨詢他人的情況下做出決策。這不是最好的做法。作為開發(fā)人員，對自己能力作出判斷，意識到自己所了解的很少，是非常重要的。
10. 繼承一切
繼承本身并不是壞事。但是，很多人是把以前的東西照單全收，從而導(dǎo)致濫用。如果發(fā)現(xiàn)自己使用了很多前人的內(nèi)容，可能已經(jīng)過度設(shè)計(jì)了。
過度設(shè)計(jì)可能會導(dǎo)致代碼的設(shè)計(jì)過于大眾化，以致于忽視了最初設(shè)計(jì)要執(zhí)行的主要任務(wù)。代碼因此變得難以使用，而且從根本上來說，這是不明智的。
正如所言，繼承并不總是壞事，只是并非修復(fù)問題的第一選擇。
想要成為出色的開發(fā)人員，犯錯不是不被允許的，畢竟，人們一直以來做的，就是不斷犯錯，再不斷吸取教訓(xùn)繼續(xù)前行。
網(wǎng)站標(biāo)題：教科書級錯誤：每個開發(fā)人員都犯過的典型錯誤
鏈接分享：http://www.5511xx.com/article/cdccgog.html
