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