不用擔(dān)心，每個開發(fā)人員都會時常犯錯誤

犯錯誤是使我們成為人類的原因。 這件事不應(yīng)該讓您感到太多困擾，因?yàn)樗鼘γ總€開發(fā)人員而言都經(jīng)常發(fā)生。 而且仍然每天都發(fā)生在我們所有人身上。

[[322917]]

軟件開發(fā)非常困難，因此錯誤總是會發(fā)生。 一個錯誤比其他錯誤具有更大的影響力，但錯誤始終存在。 犯錯誤的地方是完全可以的。 實(shí)際上，錯誤是使我們成長的原因。

您可以利用此列表中的錯誤并向他們學(xué)習(xí)，以便成為更好的開發(fā)人員。 正如埃莉諾·羅斯福(Eleanor Roosevelt)曾經(jīng)說過的：從別人的錯誤中學(xué)習(xí)。 您不能活到足以讓他們自己生活。

一個不會犯錯誤的人根本不會做任何事情-Giacomo Casanova

10.過于自信

許多開發(fā)人員過于自信。 當(dāng)然，擁有信心是一件很棒的事情-但在一定程度上。 當(dāng)您對開發(fā)人員過于自信時，您將很難看到從他人那里獲得反饋的好處。

過于自信的開發(fā)人員完全會錯失一個事實(shí)，那就是他們也會犯錯誤，因此他們傾向于在不咨詢他人的情況下做出決策。 這不是最好的事情，因?yàn)樗鼤谀硞€時候咬住你，或者是以不選擇最佳方法的形式出現(xiàn)，或者是以其他被低估的開發(fā)人員的形式出現(xiàn)。

作為開發(fā)人員，很高興知道自己知道多少，并意識到自己所了解的很少。

9.繼承一切

繼承本身不一定很糟糕。 但是，我看到許多開發(fā)人員犯的一個經(jīng)典錯誤是他們過度使用了它，這可能導(dǎo)致濫用。 如果您發(fā)現(xiàn)自己使用了很多繼承，則可能是工程過度。

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

正如我所說，繼承并不總是不好的。 修復(fù)問題可能不是您的第一選擇。

8.缺乏實(shí)踐

實(shí)踐使完美，每個人都知道。 因此，為了擴(kuò)展您的技能，您需要更多的練習(xí)。 不時不學(xué)新事物是您作為開發(fā)人員可能犯的最大錯誤之一。

如果您想學(xué)習(xí)一種新技術(shù)或編程語言，則可能不得不在日常工作之外進(jìn)行。 為了保持相關(guān)性，這是您必須對自己進(jìn)行的一項(xiàng)投資。

如果您認(rèn)為可以練習(xí)，我寫了一篇文章，其中列出了可以構(gòu)建的有趣的附帶項(xiàng)目。

7.由于缺乏知識而重新發(fā)明輪子

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

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

這導(dǎo)致浪費(fèi)時間來生產(chǎn)框架中已經(jīng)存在的代碼。 缺乏經(jīng)驗(yàn)還導(dǎo)致無法充分利用框架的潛力。

6.不提交正確的文件

我經(jīng)?？吹秸_的文件沒有提交到存儲庫。 這有兩種程度：一次提交的文件過多或一次提交的文件遺漏。

有時提交了太多文件。 我沒有指望看到IDE文件最終存儲在存儲庫中的次數(shù)。 這主要與開發(fā)人員做得不好有關(guān)。 盲目地將所有文件添加到提交中通常是不好的。

一個文件何時在提交中被遺漏的示例可能是缺少的yarn.lock文件。 在大多數(shù)情況下，這與缺乏知識或理解有關(guān)。 開發(fā)人員不知道文件的用途，因此害怕將其添加到存儲庫中。 或者他們可能認(rèn)為該文件僅適用于其本地環(huán)境。

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

5.認(rèn)為您不需要測試代碼

"這段代碼是如此之小，以至于不會影響任何重要的事情。"

每個開發(fā)人員都編寫了很小的代碼，以至于不會破壞任何主要內(nèi)容。 而且它仍然設(shè)法破壞了某些東西。 您添加的兩行代碼成功打破了您無法預(yù)料的內(nèi)容。

大多數(shù)開發(fā)人員都討厭測試其代碼。 有些人看不到目標(biāo)，認(rèn)為這是浪費(fèi)時間。 經(jīng)常被不切實(shí)際的備份

您怎么知道您的代碼可以完美運(yùn)行?

請讓您的話語得到一些實(shí)際測試的支持。 全面的測試可以過濾出關(guān)鍵的錯誤，從而確保代碼按預(yù)期的方式運(yùn)行。

4.低估工作量

"我可以輕松地在一個故事點(diǎn)上實(shí)現(xiàn)此功能。"

好吧，事實(shí)證明事情并沒有您想象的那么容易。 您嘗試的第一個解決方案未達(dá)到預(yù)期的效果。 事實(shí)證明，解決該問題的另一種方法花費(fèi)了更多時間。

低估工作負(fù)載是一個經(jīng)常發(fā)生的經(jīng)典錯誤。 尤其是當(dāng)團(tuán)隊(duì)使用諸如Scrum之類的敏捷方法時，您會發(fā)現(xiàn)這種錯誤經(jīng)常發(fā)生。

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

3.編寫太花哨的代碼

尤其是沒有那么多經(jīng)驗(yàn)的開發(fā)人員在其編碼生涯中有一段時期，他們試圖打動其他開發(fā)人員。

不要花太多時間在編寫最完美的代碼上。 出于目的編寫代碼并使其按預(yù)期工作。 這給您留下了很多額外的時間，您可以繼續(xù)努力甚至為客戶帶來更多價(jià)值。

2.快速和骯臟

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

但是，在某些情況下，快速而骯臟可能并不重要。 在某些情況下，這實(shí)際上可能是正確的方法。 例如，代碼壽命短時。

但是，從長遠(yuǎn)來看，當(dāng)您需要代碼時，快速又骯臟的修復(fù)工作會再次吸引您。

1.在錯誤的分支中提交代碼

我們將以一個錯誤立即開始發(fā)現(xiàn)該錯誤，該錯誤不會產(chǎn)生重大影響。 盡管您可能會浪費(fèi)大量時間來修復(fù)此錯誤。

在錯誤的分支中提交代碼是我們至少做過一次的事情。 如果您及時發(fā)現(xiàn)此錯誤，則可以輕松解決。 當(dāng)您開始在錯誤的分支中提交代碼時，它將變得更加棘手。

總結(jié)

現(xiàn)在，我們已經(jīng)遍歷了每個開發(fā)人員可能犯的經(jīng)典錯誤列表，明智的做法是花一兩分鐘的時間來學(xué)習(xí)這些錯誤。

當(dāng)您要成為一名更好的開發(fā)人員時，必須記住，犯錯是完全可以的。 剩下的就是讓您不斷弄臟自己的手，這樣就可以從可以學(xué)習(xí)的地方犯錯誤。