本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)

[[359315]]

 犯錯是人之常情，也是促進我們成長的關鍵，不必懼怕犯錯。請試著從他人的錯誤中學習借鑒，以免今后重蹈覆轍。

• 在長壽命的代碼中使用快速粗糙的修復程序?？焖俅植诘慕鉀Q方案會破壞代碼庫的質(zhì)量，很可能增加不必要的技術(shù)負擔。長遠來看，這樣的方案會造成反噬。最后很可能需要重構(gòu)。
• 缺乏實踐。熟能生巧，要想成為一名開發(fā)人員需要更多的實操。最大錯誤是忘記時不時得學習新事物。如果想學習編程語言之類的新知識，大概率需要利用業(yè)余時間。
• 低估工作量。估測工作量是軟件開發(fā)的一大難事。在Scrum疏理時經(jīng)常有人說“這小功能一個故事點就能搞完”。但任務可能并不簡單，預期方案也不起作用。所以在估測時記得計入測試時間，這點不僅適用于開發(fā)人員。
• 寫顯而易見的注釋。我們都曾看過這樣的注釋：什么也沒解釋，只專注于代碼的功能(例如，foreach循環(huán)的注釋寫著“產(chǎn)品遍歷循環(huán)”)。當寫注釋時，不要只關注代碼是做什么的，要關注此代碼的創(chuàng)建原因。
• 注釋掉代碼塊。代碼塊中多個功能被注釋掉的情況比較常見。沒有人知道代碼塊仍然存在的原因或是否有用。沒有人刪除是因為每個人都認為其他人可能需要它，大膽刪除注釋掉的代碼塊。如果代碼仍然有用，可在版本控制中找到。
• 僅測試基本邏輯方案。在編寫測試時不要只考慮基本邏輯，也要思考預期之外的情況，記得測試最壞的情況。
• 代碼格式凌亂。這是經(jīng)驗不足的開發(fā)人員最常犯的錯誤。它使代碼更難閱讀，也會給其他需要閱讀代碼的開發(fā)人員帶來困擾。通過安裝格式化代碼的linter可以修復凌亂的代碼。
• 不記錄任何相關信息。有用的日志可以為開發(fā)人員提供極大的幫助。日志消息可以幫助洞悉代碼的問題所在，并節(jié)省大量調(diào)試時間。發(fā)生特定錯誤時，好的日志消息會提供有關用戶正在執(zhí)行的操作信息。
• 由于缺乏認知而重新開發(fā)wheel。當開發(fā)人員不知道框架中有哪些功能時，就會發(fā)生此錯誤。由于缺乏認知，開發(fā)人員實施的新方法會與框架中已有的幾乎相同。
• 在沒有解決方案的情況下開始編碼。剛開始可能令人興奮，但最終會反噬回來。計劃和組織代碼是編碼的重要組成部分。不要不做計劃就開始編碼，編寫代碼之前，有很多事情要考慮。
• 不好的提交說明。很多人都有過這樣的經(jīng)歷。“修復錯誤”或“ WIP”都不是很好的提交說明。好的提交說明很重要，應該多花一些時間將它寫好。好的提交說明可提供內(nèi)容更改和更改原因的有用信息。出現(xiàn)問題時，修訂歷史記錄是快速找出病癥所在的重要資源。
• 代碼中包含魔數(shù)。魔數(shù)是特定值，它具有無法解釋的含義，出現(xiàn)多次，可以并且應該以命名常量替換。魔數(shù)不可讀，并且不為開發(fā)人員提供任何信息。最重要的是，魔數(shù)經(jīng)常多次用于程序中的不同位置，很容易產(chǎn)生錯誤。
• 一個功能中要素太多。試著讓功能做好一件事。不要讓這個功能同時獲取、處理和輸出數(shù)據(jù)。將所有這些職責劃分為不同的職能。一個用于獲取，一個用于處理，另一個用于輸出數(shù)據(jù)。功能專注于單項是使它更強大的關鍵。
• 不編寫自動化測試。起初編寫自動化測試會比手動測試花費更多時間。長遠來看，多花時間編寫這些自動化測試是值得的。手動測試所有內(nèi)容無聊又耗時，并且人為因素更容易出錯。
• 不必要的復雜化。大多開發(fā)人員都有過為了實施特定設計模型而實施的行為。僅僅因為有機會實施某種設計模式不意味著就應該這樣做，這樣做只會增加代碼庫的技術(shù)負擔。

這些錯誤你犯過么?有則改之，無則加勉，這些坑要注意起來啦。