全文共1713字，預計學習時長5分鐘
犯錯是人之常情，也是促進我們成長的關鍵，不必懼怕犯錯。請試著從他人的錯誤中學習借鑑，以免今後重蹈覆轍。
· 在長壽命的程式碼中使用快速粗糙的修復程式。快速粗糙的解決方案會破壞程式碼庫的質量，很可能增加不必要的技術負擔。長遠來看，這樣的方案會造成反噬。最後很可能需要重構。
· 缺乏實踐。熟能生巧，要想成為一名開發人員需要更多的實操。最大錯誤是忘記時不時得學習新事物。如果想學習程式語言之類的新知識，大機率需要利用業餘時間。
· 低估工作量。估測工作量是軟體開發的一大難事。在Scrum疏理時經常有人說“這小功能一個故事點就能搞完”。但任務可能並不簡單，預期方案也不起作用。所以在估測時記得計入測試時間，這點不僅適用於開發人員。
· 寫顯而易見的註釋。我們都曾看過這樣的註釋：什麼也沒解釋，只專注於程式碼的功能（例如，foreach迴圈的註釋寫著“產品遍歷迴圈”）。當寫註釋時，不要只關注程式碼是做什麼的，要關注此程式碼的建立原因。
· 僅測試基本邏輯方案。在編寫測試時不要只考慮基本邏輯，也要思考預期之外的情況，記得測試最壞的情況。
· 程式碼格式凌亂。這是經驗不足的開發人員最常犯的錯誤。它使程式碼更難閱讀，也會給其他需要閱讀程式碼的開發人員帶來困擾。透過安裝格式化程式碼的linter可以修復凌亂的程式碼。
· 不記錄任何相關資訊。有用的日誌可以為開發人員提供極大的幫助。日誌訊息可以幫助洞悉程式碼的問題所在，並節省大量除錯時間。發生特定錯誤時，好的日誌訊息會提供有關使用者正在執行的操作資訊。
· 由於缺乏認知而重新開發wheel。當開發人員不知道框架中有哪些功能時，就會發生此錯誤。由於缺乏認知，開發人員實施的新方法會與框架中已有的幾乎相同。
· 在沒有解決方案的情況下開始編碼。剛開始可能令人興奮，但最終會反噬回來。計劃和組織程式碼是編碼的重要組成部分。不要不做計劃就開始編碼，編寫程式碼之前，有很多事情要考慮。
· 不好的提交說明。很多人都有過這樣的經歷。“修復錯誤”或“ WIP”都不是很好的提交說明。好的提交說明很重要，應該多花一些時間將它寫好。好的提交說明可提供內容更改和更改原因的有用資訊。出現問題時，修訂歷史記錄是快速找出病症所在的重要資源。
· 程式碼中包含魔數。魔數是特定值，它具有無法解釋的含義，出現多次，可以並且應該以命名常量替換。魔數不可讀，並且不為開發人員提供任何資訊。最重要的是，魔數經常多次用於程式中的不同位置，很容易產生錯誤。
· 一個功能中要素太多。試著讓功能做好一件事。不要讓這個功能同時獲取、處理和輸出資料。將所有這些職責劃分為不同的職能。一個用於獲取，一個用於處理，另一個用於輸出資料。功能專注於單項是使它更強大的關鍵。
· 不編寫自動化測試。起初編寫自動化測試會比手動測試花費更多時間。長遠來看，多花時間編寫這些自動化測試是值得的。手動測試所有內容無聊又耗時，並且人為因素更容易出錯。
· 不必要的複雜化。大多開發人員都有過為了實施特定設計模型而實施的行為。僅僅因為有機會實施某種設計模式不意味著就應該這樣做，這樣做只會增加程式碼庫的技術負擔。
這些錯誤你犯過麼？有則改之，無則加勉，這些坑要注意起來啦。
我們一起分享AI學習與發展的乾貨