新手程序員常見錯誤分析，pt。1個

你好世界！一旦你學會了你需要知道的一切並最終開始作為實習生或初級開發人員工作，你就可以放鬆了，對吧？沒有。一切對你來說才剛剛開始……你被許多新的和難以理解的事物所包圍。你怎麼不把它搞砸了？這就是我們今天要討論的內容。在這篇文章中，我想分析菜鳥常見的錯誤，並根據我自己的經驗給出一些關於如何避免這些錯誤的建議。 那麼，讓我們開始吧，不用多說：

1. 害怕向更有經驗的同事尋求幫助

我們都是人。我們都害怕看起來很愚蠢，尤其是在我們更有經驗的新同事眼中。當開發人員開始他們的第一份工作時，他們常常被這種恐懼所引導，並在沉重的壓力下退縮到自己身邊，試圖自己解決所有問題。此外，一個人周圍可能有更有經驗的同事，這些同事反過來又能為他或她指明最有前途的方向，幫助避免更多的錯誤和不必要的“麻煩”。所以請記住：不要害怕提問。您是初學者，每個人都非常了解這一點。當你提出要求時，沒有人會用棍子打你。甚至可能會發生相反的情況：你會更快地與同事成為朋友，並開始享受與他們更積極的交流。我' 我會說得更多：你提出和討論各種技術問題的次數越多，你就能越快擺脫你的新手綠色皮膚並成長為你所在領域的專家。還有一條建議。不要陌生計算器。我是專門談論在這個資源上提問的。一方面，需要一些時間才能得到您問題的答案。但另一方面，您可能會很快學會多種解決問題的方法，並從稍微不同的角度看待問題。我還想指出，撰寫評論/答案和撰寫澄清其他開發人員提出的關於 StackOverflow 問題的問題有實際好處：您有機會辯論和深入研究問題，更不用說業力提升了。

2. 不嘗試自己搜索信息

這個錯誤可以被認為是前一個錯誤的反面。在這裡我的意思是當你開始糾纏你的同事和熟人關於你遇到的每一個問題或小問題時。問是好的，但不要過度提問。否則，人們可能只會覺得你很煩人。如果你對某件事感到困惑，首先要做的就是在最好的搜索引擎——谷歌上鍛煉你的搜索技巧。其他人已經遇到了絕大多數無法理解的錯誤和其他問題。如果您用谷歌搜索您的問題並看到熟悉類似問題的人數，並且已經收到您可以在自己的工作中應用的詳盡答案，您會感到非常驚訝。這就是為什麼您會經常聽到您的同事回复“Google it”。大學教師' 不要被這個答案冒犯——你的同事不是你的私人老師，他必須傳達你工作領域的所有微妙之處。無邊無際的互聯網將是你的良師益友。有時程序員也被稱為在 Google 搜索中獲得黑帶的人。所以如果我們有一個“打嗝”，我們首先用谷歌搜索這個問題。如果找不到解決方案（這種情況很少見，但確實會發生），我們才會開始詢問同事。直接問題是為了獲得關於應該選擇哪種方法來解決問題的建議，而不是當你遇到減速帶或無法理解的錯誤消息時你會做什麼。畢竟，他們可能能夠超越您的首選方法，並立即預測任何給定方法從長遠來看會走向何方。

3、盲目複製粘貼

但是谷歌搜索問題及其解決方案有其缺陷。比如盲目的複制粘貼。當您發現類似的問題（但可能不完全相同）和相關的解決方案時，通常會發生這種情況，例如，在 StackOverflow 上。您獲取此解決方案並複制並粘貼它，而無需進一步深入研究細節。然後您或您的同事會在您的代碼中發現一些奇怪的錯誤或不正確的行為。沒有人能立即猜出它們來自哪裡。最終當然會找到復制代碼的地方，你的解決方案肯定不會被表揚。因此，當您在 StackOverflow（或其他任何地方）上找到現成的解決方案時，您必須首先徹底了解 what、how 和 why。也許谷歌相關功能並閱讀它的文檔。只有在你完成之後，你才應該將它添加到你的項目中。

4.堅持錯誤的解決方案

在編寫解決方案時，有時會發現它不斷地變得越來越複雜，最終走到了死胡同。然後你嘗試使解決方案更加詳盡，以便以某種方式使其發揮作用，而不是尋找另一個更合適的替代方案。也許你覺得自己投入了很多時間和精力，因此決定無論如何都不會放棄，你會用現有的方法解決問題。這不是完全正確的態度。至少在編程方面。越早嘗試不同的方法，最終節省的時間就越多。因此，無論您在當前方法上投入了多少時間，都不要害怕嘗試其他方法。更重要的是，通過嘗試多種方法並更深入地研究該主題，您

5. 害怕詢問有關您當前任務的問題

從事軟件開發項目通常歸結為執行特定任務。例如，在吉拉. 這些任務並不總是清晰詳細地概述。任務描述通常由團隊負責人撰寫，他們也不過是凡人。他們可能會忘記添加一些東西，或者沒有說明您不熟悉這個或那個功能的事實。或者，您可能沒有對該項目的任何訪問權限（例如，對數據庫、日誌服務器等的訪問權限）。而現在，你接到了任務，研究了兩個多小時，卻還坐在那裡，茫然地盯著屏幕。與其繼續嘗試理解這一點，但沒有成功，您應該開始向創建任務的人尋求澄清或指導。例如，在你的團隊用於交流的應用程序（例如 Microsoft Teams）中，你可能會就任務提出問題或直接發表評論。一方面，如果您將問題寫在個人消息中，您可能會更快得到答复，因為對方會立即看到您的問題。另一方面，通過在 Jira 中提問，您可以證明您正在做某事，即分析問題。有一種方法可以加速此過程：在 Jira 的評論中提出您的問題，然後在 DM 中，添加指向您評論的鏈接並要求查看。

6. 對團隊領導寄予不切實際的高期望

同樣，這是前一點的反面。團隊負責人是開發團隊的負責人。通常，您的團隊領導將大部分時間花在各種溝通上。然而，他或她也編寫代碼，以便不忘記關於編程的一切。如您所知，團隊負責人的生活非常忙碌。每次你需要打噴嚏時拉著你的團隊領導的袖子顯然是不愉快的。想像一下團隊中的每個成員都用一堆問題轟炸領導。這會讓任何人發瘋，對吧？如果你堆積了很多問題，那麼你的團隊領導將不得不花很多時間來回答你。可以做些什麼來減少針對團隊領導的問題數量：

• 更深入地探索項目文檔以減少盲點的數量。
• 將您的問題轉給您的其他團隊成員。他們可能和領導一樣熟悉這個功能，甚至可能更熟悉，因為這個功能很可能是由他們中的一個人編寫的。

或者，您可以查看 IDE 中的註釋，了解特定行中的代碼最後一次更改的人員和時間。這正是您如何找出最適合提出問題的人。正如您可能已經意識到的那樣，當涉及到向團隊負責人提問時，就像向同事提問一樣，您需要嘗試找到一個快樂的媒介——不要害怕提問，但也不要問太多他們中的。

7. 害怕代碼審查

代碼審查就是這樣一個階段，發生在你將你的代碼提交到一個公共應用程序（到一個共享分支，例如 master 或 dev）之前。此檢查由未參與該任務的開發人員執行，他們的新鮮眼光可以檢測您的代碼風格中的錯誤、不准確或缺陷，這些錯誤、不准確或缺陷在您最初編寫代碼時沒有被注意到。如果有批評，它們將作為對代碼某些部分的評論留下。在這種情況下，編寫代碼的開發人員必須更正審查中發現的錯誤（或與審查者討論他的決定，可能說服他或她他們是正確的）。然後代碼一次又一次的提交review，直到reviewer沒有更多意見為止。在提交代碼之前，審閱者充當“網關”。挑戰在於許多新手程序員將代碼審查視為批評和譴責。他們不欣賞代碼審查並且害怕它們。他們不應該。代碼審查正是讓我們改進代碼的原因。畢竟，我們收到了關於我們做錯了什麼以及什麼值得關注的重要信息。您應該將每次代碼審查視為學習曲線的一部分，這可以幫助您變得更好。當有人評論您的代碼時，他或她正在與您分享經驗和最佳實踐。我個人認為如果不進行代碼審查，您就無法成為一名優秀的程序員。因為你甚至不知道你的代碼的質量，也不知道有經驗的局外人是否會指出錯誤。不欣賞代碼審查並且害怕它們。他們不應該。代碼審查正是讓我們改進代碼的原因。畢竟，我們收到了關於我們做錯了什麼以及什麼值得關注的重要信息。您應該將每次代碼審查視為學習曲線的一部分，這可以幫助您變得更好。當有人評論您的代碼時，他或她正在與您分享經驗和最佳實踐。我個人認為如果不進行代碼審查，您就無法成為一名優秀的程序員。因為你甚至不知道你的代碼的質量，也不知道有經驗的局外人是否會指出錯誤。不欣賞代碼審查並且害怕它們。他們不應該。代碼審查正是讓我們改進代碼的原因。畢竟，我們收到了關於我們做錯了什麼以及什麼值得關注的重要信息。您應該將每次代碼審查視為學習曲線的一部分，這可以幫助您變得更好。當有人評論您的代碼時，他或她正在與您分享經驗和最佳實踐。我個人認為如果不進行代碼審查，您就無法成為一名優秀的程序員。因為你甚至不知道你的代碼的質量，也不知道有經驗的局外人是否會指出錯誤。做錯了什麼以及值得關注的地方。您應該將每次代碼審查視為學習曲線的一部分，這可以幫助您變得更好。當有人評論您的代碼時，他或她正在與您分享經驗和最佳實踐。我個人認為如果不進行代碼審查，您就無法成為一名優秀的程序員。因為你甚至不知道你的代碼的質量，也不知道有經驗的局外人是否會指出錯誤。做錯了什麼以及值得關注的地方。您應該將每次代碼審查視為學習曲線的一部分，這可以幫助您變得更好。當有人評論您的代碼時，他或她正在與您分享經驗和最佳實踐。我個人認為如果不進行代碼審查，您就無法成為一名優秀的程序員。因為你甚至不知道你的代碼的質量，也不知道有經驗的局外人是否會指出錯誤。

8. 做出神秘決定的傾向

各種任務/問題通常可以有幾種不同的解決方案。在所有可用的解決方案中，初學者傾向於使用最複雜和神秘的解決方案。這是有道理的：就在昨天，新手程序員學習了很多不同的算法、模式和數據結構，因此他們迫不及待地想要實現其中的一些。相信我，我就是那樣的人，所以我知道我在說什麼 :) 我曾遇到過很長一段時間都在實現某些功能的情況。結果非常非常複雜。然後高級開發人員重寫了我的代碼。當然，我很想看看他改變了什麼以及如何改變它。我查看了他的實現，並對它的簡單程度感到驚訝。而且代碼少了三倍。同樣令人驚訝的是，此功能的自動化測試沒有被刪除或更改！換句話說，一般邏輯保持不變。由此，我得出的結論是最巧妙的解決方案總是很簡單。意識到這一點後，編碼變得容易多了，我的代碼質量也跳到了一個更高的水平。那麼什麼時候值得應用設計模式和花哨的算法，你會問？應用它們將是最簡單和最緊湊的解決方案。

9. 重新發明輪子

輪子是很久以前發明的一種耐用解決方案。在這種反模式中，開發人員針對已經解決的問題實施他或她自己的專有解決方案。有時這些現有的解決方案比程序員想出的要好。通常，重新發明輪子會導致時間浪費和生產力下降，因為您找到的解決方案可能遠非最佳解決方案，或者，您可能根本找不到。也就是說，我們不能排除創建我們自己的獨立解決方案的可能性：如果我們這樣做了，那麼剩下的就是複制和粘貼編程。無論是使用現成的解決方案還是創建定制的解決方案，程序員都應該以出現的特定編程任務為指導，以便勝任和迅速地解決它們。一方面，在大學和在線課程中，我們被各種各樣的任務轟炸，這些任務似乎旨在幫助我們重新發明輪子。但乍一看：這裡的真正目的是培養算法思維和更深入地掌握語言語法。此類任務還可以幫助您更好地理解算法和數據結構，並在必要時為您提供實施更複雜對應物的技能（這有時是必要的，但極為罕見）。在現實生活中，絕大多數情況下你不需要自己發明輪子，因為滿足你需求的輪子早已存在。也許您的經驗不足使您無法了解所需功能的實現。這是您需要採納本文第一點中給出的建議的地方，即，向更有經驗的同事尋求幫助。他們將能夠指導您（例如，在您的 Google 搜索中為您指明正確的方向）或建議具體的實施方式（例如，某些圖書館）。

10. 沒有寫測試

所有新手都不喜歡寫測試。但是我們為什麼要在這裡挑出新手呢？更多經驗豐富的開發人員也不喜歡編寫測試，但他們更了解為什麼需要測試。當你完全是綠色的時候，你想知道為什麼要寫它們。一切正常，所以不會有任何錯誤。但是您如何確保您的更改不會破壞系統中其他地方的某些東西？如果您推行弊大於利的變革，您的同事將不會感激。這是測試來拯救我們的地方。測試覆蓋的應用程序代碼越多越好（這稱為代碼覆蓋率或測試覆蓋率）。如果應用程序具有良好的測試覆蓋率，那麼您可以運行所有測試以查找將被您的代碼破壞的地方。正如我在上面的例子中所說的，當高級開發人員重構代碼時，測試沒有失敗。這是因為一般邏輯沒有改變。我們使用測試來證明某些功能的邏輯是否發生了變化。因此，即使您不喜歡編寫測試，它們也絕對有用並且非常值得花時間在上面。

11. 過度評論

許多開發人員患有完美主義，新手也不例外。當他們開始評論每個人和每件事時，有時他們只會表現出這種傾向的一個方面。甚至進行不必要的註釋，因為代碼非常明顯：

Cat cat = new Cat(); // Cat object

並不是所有的新手程序員都能立即意識到註釋代碼並不總是好的，因為多餘的註釋會使代碼混亂並難以閱讀。如果代碼發生變化，但舊註釋沒有更新怎麼辦？那他們只會誤導我們，使我們迷惑。那為什麼要發表這樣的評論呢？通常，編寫良好的代碼不需要註釋，因為其中的所有內容都已經顯而易見且可讀。如果您需要寫註釋，那麼您已經破壞了代碼的可讀性並且正在嘗試以某種方式補救這種情況。最好的方法是從一開始就編寫可讀代碼，即不需要註釋的代碼。我也忍不住提到需要遵循正確的方法、變量和類命名約定。這是我的規則： 最好的註釋要么沒有註釋，要么正確命名，清楚地描述您的應用程序中的功能。

12. 糟糕的命名

新手在類、變量、方法等的命名上玩得既快又鬆散。例如，創建一個名稱根本無法描述其用途的類。或者他們用短名稱聲明一個變量，例如x。他們在另外兩個名為n和y的變量時被創建，記住 x 負責什麼變得非常困難。面對這種情況，您必須仔細考慮代碼，在顯微鏡下分析它（可能使用調試器），研究功能，以便簡單地了解發生了什麼。這就是我上面提到的正確命名約定對我們有所幫助的地方。正確的名稱可以提高代碼的可讀性，從而減少您熟悉代碼所需的時間，因為當方法的名稱大致描述其功能時，使用方法要容易得多。代碼中的一切都由名稱（變量、方法、類、對象、文件等）組成，因此在創建正確、乾淨的代碼時這一點變得非常重要。您應該記住，名稱應該傳達含義，例如變量存在的原因，它的作用，以及它是如何使用的。我會不止一次地指出，對變量最好的註釋是給它起一個好名字。為了更深入地研究評論和正確的命名，我推薦閱讀永恆的經典：“整潔代碼：敏捷軟件工藝手冊”，作者 Robert Martin。關於這一點，本文的第一部分（我的思考）已經結束。待續...