新手程式設計師典型錯誤分析：第1部分

你好世界！ 當您了解了所需的一切並最終被聘為實習生或初級員工後，您可能可以放鬆，對嗎？不管怎麼樣！一切才剛開始……周圍有很多新鮮的、難以理解的事情，一出門怎麼不搞砸呢？這就是我們今天要討論的內容。在這篇文章中，我想看看初學者常犯的錯誤，並根據我自己的經驗給出一些如何避免這些錯誤的提示。那麼，讓我們開始吧：

1. 害怕向較有經驗的同事尋求協助

我們都是人，都害怕自己看起來很愚蠢，尤其是在我們新成立的、經驗更豐富的同事眼中。一旦獲得第一份工作，開發人員常常會屈服於這種恐懼，無法自拔地自我封閉，試圖自己解決一切問題。同時，一個人周圍可以有更有經驗的同事，他們反過來能夠初步引導他走上最正確的道路，這將有助於避免更多的錯誤和不必要的「坎坷」。因此，請記住：不要害怕提問：您是初學者，每個人都完全理解這一點。當你提出要求時，沒有人會用棍子打你。也許甚至是相反的：你會更快地與同事交朋友，並開始更積極地與他們溝通。我還要說的是：你問和討論各種技術問題越多，你就能越快擺脫新手的困境，成長為你所在領域的專家。還有一條建議。不要忽略StackOverFlow。在這種情況下，我的意思是詢問有關此資源的問題。一方面，需要一些時間才能得到問題的答案。但另一方面，你可能會立即了解解決當前問題的幾種方法，並從稍微不同的角度來看待它。我還想指出的是，在 StackOverFlow 上寫下評論和答案，澄清其他開發者提出的問題，除了因果報應之外，還有一個實際的好處：你有機會更深入地討論和理解這個問題。

2.不要試圖自己尋找訊息

也許這個錯誤是前一個錯誤的反面。我的意思是，當你開始向你的同事和熟人拉扯每一個問題時。提問是好事，但你不應該問太多問題，否則你可能會感到無聊。如果出現一些難以理解的問題，首先要做的就是在最好的搜尋引擎——Google 中運用你的搜尋技巧。有人已經遇到了絕大多數難以理解的錯誤和其他問題。如果你用谷歌搜尋一下，看到有多少人熟悉類似的問題，並且已經收到了適合在他們的工作中使用的全面答案，你會感到非常驚訝。基於此，你經常可以聽到同事回答一個問題—「Google it」。您不應該被這個答案冒犯，因為畢竟，您的同事不是應該傳達您工作領域的所有複雜性的私人老師。無窮無盡的互聯網將幫助您進行此類指導。有時，程式設計師在 Google 搜尋中也被稱為黑帶人士。因此，當我們陷入困境時，我們首先用谷歌搜尋問題，如果沒有找到解決方案（很少，但確實會發生），然後我們開始詢問我們的同事。值得立即詢問他們，不是在出現某種故障或難以理解的錯誤時，而是在選擇解決問題的方法時。畢竟，他們能夠超越你的視野，並立即判斷這種或那種方法從長遠來看會產生怎樣的結果。

3.盲目複製貼上

但谷歌搜尋這個問題及其解決方案也有其缺陷。例如，盲目複製貼上。當您發現類似的問題（但可能不完全相同）並且在其下方（例如在 StackOverFlow 上）有一個解決方案時，通常會發生這種情況。您可以自行複製並貼上此解決方案，無需了解太多細節。然後您或您的專案同事發現了一些奇怪的錯誤或功能的不正確行為。沒有人知道腿從哪裡來。那麼，當然，會找到有這個代碼的地方，你的這個決定肯定不會受到讚揚。因此，當你在StackOverFlow（或其他地方）上找到現成的解決方案時，首先你必須詳細分析它，它是什麼，如何以及為什麼。也許谷歌一下這個功能並查看它的文檔。然後才將其實施到您的專案中。

4. 拋出錯誤的解決方案

在編寫解決方案時，有時會變得越來越複雜並最終陷入死胡同。您正在嘗試使其變得越來越複雜，以便使用這種方法以某種方式解決這個問題，而不是試圖尋找另一種更可行的替代方案。也許你只是對自己所花費的精力和時間感到遺憾，所以你決定：無論如何，都不要放棄，而是這樣解決問題。這並不完全是正確的做法。至少在程式設計方面是如此。越早嘗試不同的方法，最終節省的時間就越多。因此，儘管您在這一方法上投入了大量時間，但不要害怕嘗試其他方法。此外，這些將是您的經驗點，因為您將嘗試多種方法並更好地研究該領域。

5. 害怕提出有關當前任務的問題

專案工作通常歸結為完成一些任務（任務）。例如，在Jira中。而且這些任務並不總是被詳細和清晰地描述。它們通常是由團隊領導者編寫的，如果發生這種情況，這些人也是人。他們也可能忘記添加某些內容，或者沒有考慮到您對這個或那個功能不是很熟悉。好吧，或者您沒有對該項目的任何存取權限（例如，訪問資料庫、日誌伺服器等）。而現在，接到任務，研究了幾個小時後，你仍然坐在那裡一臉茫然地看著螢幕。您應該開始向此任務的創建者提出引導性/澄清性問題，而不是繼續無濟於事地解決這個問題。假設您在團隊（例如 Microsoft Teams）中用於通訊的應用程式中，或直接作為此任務下的評論。一方面，如果您在個人訊息中寫下問題，很可能會更快得到答案，因為人們會立即看到問題。另一方面，透過在 Jira 中提出問題，您有證據表明您正在做某事，即分析問題。有一種方法可以加快此過程：在 Jira 中以評論形式提出問題，並在私人訊息中發送該評論的連結並要求查看。

6. 對團隊領導期望過高

這又是前一點的反面。團隊領導是開發團隊的負責人。一般來說，這樣的團隊成員大部分的時間都花在各種類型的溝通上。同時，他也編寫程式碼，以免忘記這一切是什麼。嗯，如你所知，這是一個非常忙碌的角色。而每次打噴嚏時過度的抽搐顯然不會讓他開心。想像一下，如果每個團隊成員都用一堆問題轟炸他。所以你可以發瘋，對​​吧？如果你提出很多問題，他會花很長時間回答你，這並不奇怪。您可以採取哪些措施來減少向團隊領導者提出的問題數量：

• 更深入地研究該項目的文檔，以減少盲點。
• 向其他團隊成員提問。他們很可能與領導者一樣熟悉此功能，甚至更熟悉，因為很可能他們中的一個人編寫了該功能。

或者，在 IDE 中，您可以查看註解：誰以及何時最後更改了特定行中的程式碼。這樣我們就能找出誰最適合問這個問題。你可能已經明白了，在向組長提問時，以及在向同事提問時，你需要盡量保持中庸之道——不要害怕提問，但也不要用太多的問題來糾纏他們。

7. 害怕程式碼審查

程式碼審查或程式碼審查是將程式碼上傳到公共應用程式（公共分支，例如 master 或 dev）之前的一個階段。這項檢查是由與此任務無關的開發人員執行的，他們可以以全新的眼光發現在開發初始階段未被注意到的程式碼風格中的錯誤、不準確或缺陷。如果有註釋，它們將作為程式碼某些部分的註釋保留。在這種情況下，執行此任務的開發人員必須根據審查糾正錯誤（或與審查者討論他的決定，也許讓他相信他的決定的正確性）。然後發回審稿，以此類推，直到審稿人沒有意見為止。審閱者在上傳程式碼之前充當「過濾器」。因此，許多新手程式設計師將程式碼審查視為批評和譴責。他們不欣賞她並且害怕她，這是錯的。正是程式碼審查使我們能夠改進程式碼。畢竟，我們會收到有關我們做錯了什麼以及應該注意什麼的重要資訊。有必要將每次程式碼審查視為學習的一部分，這可以幫助您改善。當一個人對你的程式碼留下評論時，他會與你分享他的經驗和最佳實踐。對我來說，如果沒有經過程式碼審查，你就不可能成為一個優秀的程式設計師。因為你不知道從外部有經驗的人的角度來看，你的程式碼有多好，是否有錯誤。

8. 傾向深奧的解決方案

通常不同的任務/問題可以有幾種不同的解決方案。在所有可用的解決方案中，初學者通常使用最複雜和「深奧」的解決方案。這是事實：如果一個新手程式設計師昨天學習了許多不同的演算法、模式、資料結構，那麼他就會渴望實現其中的一個。是的，可以這麼說，我想聲明自己。相信我，我自己就是這樣，我知道我在說什麼:)我曾經遇到過這樣的情況：我花了很長時間編寫一個功能，結果發現它非常非常複雜。然後由高級+級別的開發人員重寫。當然，我很想知道他改變了什麼以及如何改變。我查看了他的實現，驚訝地發現它變得如此簡單。而且代碼也減少了三倍。同時，對該功能的測試沒有改變也沒有失敗！也就是說，一般邏輯保持不變。由此我得出的結論是：最巧妙的解決方案總是簡單的。認識到這一點後，編寫程式碼變得更加容易，並且明顯變得更加高級。那麼，您會問什麼時候值得使用模式和演算法呢？那麼，在使用它們的時候將會是最簡單、最緊湊的方式。

9.自行車的發明

這個概念也被稱為輪子的發明。其本質在於，開發人員針對已經存在的問題實現自己的解決方案，並且比程式設計師發明的解決方案好很多倍。一般來說，發明自己的自行車會導致時間的損失和開發人員工作效率的降低，因為可能找不到遠離最佳的解決方案，或者可能根本找不到。同時，我們也不能放棄獨立決定的可能性。程式設計師必須正確導航可能出現在他面前的任務，以便使用現成的解決方案或發明自己的解決方案及時有效地解決它們。一方面，在大學和課程中，我們面臨著各種各樣的任務，這些任務應該有助於我們動手製造自行車。但這只是乍看之下。其實這樣做的目的是為了發展演算法思維，更深入掌握語言的語法。此類任務還有助於更好地理解演算法/結構，並在必要時為他們提供實現高級類似物的技能（但這很少需要）。在現實生活中，在絕大多數情況下，沒有必要發明自己的輪子，因為滿足我們需求的類似物早已存在。也許，根據您的經驗，您將不知道您需要的這個或那個功能的實現是否存在。這時候就需要用到本文的第一點，也就是向較有經驗的同事尋求協助。他們將能夠指導您（例如，向 Google 提供建議）或建議特定的實作（某些程式庫）。

10. 不要寫測試

所有初學者都不喜歡編寫測驗。新手呢：非新手也不喜歡寫測試，但他們更能理解為什麼需要它。當你完全不懂的時候，你會想：為什麼要寫它們？一切正常，不能有任何錯誤。但是您如何確定您的變更不會破壞系統其他部分的某些內容？如果你推行的改變帶來的破壞大於他們的利益，你的同事將不會感激。這就是測試可以發揮作用的地方。測試覆蓋的應用程式越多越好（也稱為覆蓋率）。如果應用程式已被測試很好地覆蓋，那麼透過執行所有測試，您可能會發現可能因變更而損壞的地方。正如我在上面的範例中所說，在重構功能時，測試並沒有失敗，這都是因為一般邏輯沒有改變。這意味著測試還可以顯示某個功能的邏輯是否改變了。因此，即使您不喜歡編寫測試，它們也有毫無疑問的好處，並且值得在它們上花費時間。

11.過度評論

許多開發人員都患有完美主義，初學者也不例外。但有時這種願望的副作用是他們開始評論每個人、每件事。即使是不需要的，因為它是如此明顯：

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

並非所有新手程式設計師都會立即意識到註解程式碼並不總是一件好事，因為程式碼會變得更加混亂且難以閱讀。如果程式碼改了，但是沒有註解怎麼辦？事實證明，他會欺騙我們，只會讓我們感到困惑。那為什麼會有這樣的評論呢？通常，編寫良好的程式碼不需要註釋，因為其中的所有內容都已經是顯而易見且可讀的。如果您寫了註釋，則表示您已經破壞了程式碼的可讀性，並且正在嘗試以某種方式平滑這種情況。最好的方法是先編寫可讀的程式碼，而不必補充註解。我還忍不住提到了方法、變數和類別的正確命名，即我自己遵守的一條規則： 最好的註釋是沒有註釋，而是——清楚地描述這個或那個的正確命名您的應用程式中的功能。

12. 錯誤的命名

通常，初學者會偽造類別、變數、方法等的名稱。例如，當他們建立一個類別時，其名稱根本沒有描述其用途。或用一個短名稱建立一個變量，例如x，當建立另外兩個名為n和y 的變數時，就很難記住x的作用。在這種情況下，您必須仔細思考程式碼並在顯微鏡下研究此功能（可能使用偵錯器），以便簡單地了解那裡發生了什麼。這就是我上面提到的程式碼中的正確命名對我們有幫助的地方。正確的名稱可以提高程式碼的可讀性，從而節省熟悉時間，因為使用名稱大致描述其功能的方法要容易得多。在程式碼中，一切都由名稱組成（變數、方法、類別、文件物件等），這一點在創建正確、乾淨的程式碼時變得非常重要。值得記住的是，名稱應該傳達含義：例如，為什麼變數存在、它做什麼以及如何使用它。我會一次又一次地指出，描述變數的最佳註釋是它的正確名稱。為了更深入研究註釋和正確命名，我建議你閱讀永恆的經典：《乾淨的代碼》。創建、分析和重構”，羅伯特·馬丁。至此，本文第一部分（反思）就結束了。 待續…