本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)

賈科莫·卡薩諾瓦說：“不犯錯(cuò)的人一事無成。”沒有人能從不犯錯(cuò)，尤其是在軟件開發(fā)這一“艱難”的領(lǐng)域。有的錯(cuò)誤嚴(yán)重些，有的錯(cuò)誤沒有那么大的影響力。錯(cuò)誤是始終存在的。

無需為犯錯(cuò)而擔(dān)憂，事實(shí)上，犯錯(cuò)使我們成長。以下一些錯(cuò)誤是很典型的問題，幾乎每個(gè)人都經(jīng)歷過，從中吸取經(jīng)驗(yàn)，在通往優(yōu)秀開發(fā)人員的道路又進(jìn)一步。

假如你沒有，那么請從別人的錯(cuò)誤中學(xué)習(xí)。人生中沒有如此多的時(shí)間來一一經(jīng)歷所有的錯(cuò)誤。

[[326376]]

1. 快速而凌亂

大多數(shù)開發(fā)人員在職業(yè)生涯中都曾用快速而凌亂的方案來解決問題。這種方法存在一些嚴(yán)重的缺陷，從而導(dǎo)致更多的技術(shù)債務(wù)。最重要的是，快速而凌亂的解決方案可能會(huì)破壞團(tuán)隊(duì)的士氣。

也許在某些事例中，快速而凌亂可能無傷大雅。如在代碼壽命短的某些情況下，這實(shí)際上可能是正確的方法。但需要長期運(yùn)行代碼時(shí)，修復(fù)快速又凌亂的工作會(huì)反咬你一口。

2. 編寫過于花哨的代碼

尤其對(duì)于沒有足夠經(jīng)驗(yàn)的開發(fā)人員來說，在其編碼生涯中都有一段時(shí)期，試圖尋求其他開發(fā)人員的認(rèn)可。

不要花太多時(shí)間編寫最完美的代碼。按照既定目標(biāo)編寫代碼并使其按預(yù)期工作。這樣做會(huì)給自己留出很多額外的時(shí)間，從而可以創(chuàng)造更多價(jià)值。

3. 在錯(cuò)誤的分支中提交代碼

該錯(cuò)誤列表從一個(gè)小錯(cuò)誤開始——只要及時(shí)發(fā)現(xiàn)就不會(huì)產(chǎn)生重大影響。盡管開發(fā)人員可能會(huì)浪費(fèi)大量時(shí)間來修復(fù)此錯(cuò)誤。

在錯(cuò)誤的分支中提交代碼，這種事情開發(fā)員們做過不止一次。如果及時(shí)發(fā)現(xiàn)，則可以輕松解決問題。當(dāng)開始在錯(cuò)誤的分支中提交代碼時(shí)，事情就變得棘手了。 4. 低估工作量

“這很簡單嘛。”

事實(shí)證明事情并沒有想象的那么容易。嘗試的第一個(gè)解決方案并未達(dá)到預(yù)期的效果。而最后為了修復(fù)第一次未解決的問題采取的另一種方法會(huì)花費(fèi)更多時(shí)間。

低估工作量是一個(gè)經(jīng)常發(fā)生的典型錯(cuò)誤。尤其是當(dāng)團(tuán)隊(duì)使用諸如Scrum之類的敏捷方法時(shí)，這種錯(cuò)誤常有發(fā)生。

確保自己不僅要計(jì)算開發(fā)人員的時(shí)間，還需要一些時(shí)間來做其他事情，比如測試。

5. 沒有提交正確的文件

筆者經(jīng)常看到正確的文件沒有提交到存儲(chǔ)庫。這里有兩種情況：要么提交的文件過多，要么提交的文件出現(xiàn)遺漏。

有時(shí)提交了太多文件。筆者已經(jīng)見過IDE文件最終存儲(chǔ)在存儲(chǔ)庫中無數(shù)次了。這主要是因?yàn)殚_發(fā)人員工作馬虎。盲目地將所有文件添加到提交中通常并無益處。

缺少yarn.lock文件是文件在提交中出現(xiàn)遺漏的典型例子。在大多數(shù)情況下，這與知識(shí)缺乏或理解不足有關(guān)。開發(fā)人員不知道文件的用途，因此害怕將其添加到存儲(chǔ)庫中?；蛘咚麄兛赡苷J(rèn)為該文件僅適用于其本地環(huán)境。

盡管這種情況取決于丟失的文件，但在大多數(shù)情況下，此錯(cuò)誤會(huì)導(dǎo)致文件破壞。如果缺少yarn.lock，開發(fā)人員將在所有環(huán)境中獲得不同版本的依賴關(guān)系。這可能會(huì)導(dǎo)致一些令人困擾的錯(cuò)誤。

6. 由于缺乏相關(guān)知識(shí)而做無用功

大多數(shù)開發(fā)人員使用某種框架來簡化生活。如果一個(gè)開發(fā)人員正在學(xué)習(xí)框架，可能很難知道框架API中的所有可用內(nèi)容。

典型錯(cuò)誤是開發(fā)人員不知道框架中已有的功能。由于缺乏相關(guān)知識(shí)，開發(fā)人員實(shí)施了與框架中現(xiàn)有方法幾乎相同的新方法。

這導(dǎo)致時(shí)間被浪費(fèi)在生產(chǎn)框架中已經(jīng)存在的代碼。缺乏經(jīng)驗(yàn)還使開發(fā)人員無法充分挖掘框架潛力。

[[326377]]

7. 自認(rèn)為不需要測試代碼

“這段代碼很簡短，不會(huì)影響到任何重要的事情。”

每個(gè)開發(fā)人員都編寫過簡短的代碼，你以為它們不會(huì)破壞任何主要內(nèi)容，實(shí)則不然，添加的兩行代碼成功打破了無法預(yù)料的內(nèi)容。

測試代碼確實(shí)是個(gè)不招人喜歡的活兒。有些人沒有理解測試代碼的目的，認(rèn)為這是浪費(fèi)時(shí)間，常常不切實(shí)際。

怎么才知道自己的代碼能正常運(yùn)行呢?請讓一些真實(shí)的測試支持自己的話。全面的測試可以過濾出關(guān)鍵的錯(cuò)誤，從而確保代碼按預(yù)期方式運(yùn)行。 8. 缺乏練習(xí)

大家都知道熟能生巧的道理。因此，為擴(kuò)展技能，便需要更多的練習(xí)。不學(xué)習(xí)新事物是開發(fā)人員可能犯的最大錯(cuò)誤之一。

如果想學(xué)習(xí)一種新技術(shù)或編程語言，開發(fā)人員可能不得不在日常工作之外進(jìn)行學(xué)習(xí)。為了不落伍，這是必須對(duì)自己進(jìn)行的一項(xiàng)投資。

9. 過于自信

當(dāng)然，擁有信心是一件很棒的事情——但只在一定程度上。開發(fā)人員過于自信時(shí)，就很難聽得進(jìn)去別人的意見了。

過于自信的開發(fā)人員完全認(rèn)識(shí)不到自己也會(huì)犯錯(cuò)誤的事實(shí)，因此他們往往在不咨詢他人的情況下做出決策。這不是最好的做法。作為開發(fā)人員，對(duì)自己能力作出判斷，意識(shí)到自己所了解的很少，是非常重要的。

10. 繼承一切

繼承本身并不是壞事。但是，很多人是把以前的東西照單全收，從而導(dǎo)致濫用。如果發(fā)現(xiàn)自己使用了很多前人的內(nèi)容，可能已經(jīng)過度設(shè)計(jì)了。

過度設(shè)計(jì)可能會(huì)導(dǎo)致代碼的設(shè)計(jì)過于大眾化，以致于忽視了最初設(shè)計(jì)要執(zhí)行的主要任務(wù)。代碼因此變得難以使用，而且從根本上來說，這是不明智的。

正如所言，繼承并不總是壞事，只是并非修復(fù)問題的第一選擇。

想要成為出色的開發(fā)人員，犯錯(cuò)不是不被允許的，畢竟，人們一直以來做的，就是不斷犯錯(cuò)，再不斷吸取教訓(xùn)繼續(xù)前行。