不用擔(dān)心，每個(gè)開發(fā)人員都會(huì)時(shí)常犯錯(cuò)誤

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

[[322917]]

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

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

一個(gè)不會(huì)犯錯(cuò)誤的人根本不會(huì)做任何事情-Giacomo Casanova

10.過于自信

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

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

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

9.繼承一切

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

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

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

8.缺乏實(shí)踐

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

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

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

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

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

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

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

6.不提交正確的文件

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

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

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

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

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

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

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

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

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

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

4.低估工作量

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

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

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

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

3.編寫太花哨的代碼

尤其是沒有那么多經(jīng)驗(yàn)的開發(fā)人員在其編碼生涯中有一段時(shí)期，他們?cè)噲D打動(dòng)其他開發(fā)人員。

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

2.快速和骯臟

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

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

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

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

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

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

總結(jié)

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

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