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

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

[[322917]]

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

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

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

10.過于自信

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

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

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

9.繼承一切

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

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

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

8.缺乏實踐

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

如果您想學習一種新技術或編程語言，則可能不得不在日常工作之外進行。 為了保持相關性，這是您必須對自己進行的一項投資。

如果您認為可以練習，我寫了一篇文章，其中列出了可以構建的有趣的附帶項目。

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

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

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

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

6.不提交正確的文件

我經(jīng)常看到正確的文件沒有提交到存儲庫。 這有兩種程度：一次提交的文件過多或一次提交的文件遺漏。

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

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

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

5.認為您不需要測試代碼

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

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

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

您怎么知道您的代碼可以完美運行?

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

4.低估工作量

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

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

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

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

3.編寫太花哨的代碼

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

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

2.快速和骯臟

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

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

但是，從長遠來看，當您需要代碼時，快速又骯臟的修復工作會再次吸引您。

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

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

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

總結

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

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