一些讓你的代碼變得糟糕的不良習慣
壞習慣很難改變，如果你不知道你的壞習慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經來這裡看了，不是嗎？
作為一個程序員，我看到很多不好的做法，不僅僅與代碼相關，還包括團隊合作能力。我自己曾經就有不少這些壞習慣。這裡是我認為最糟糕的 35 個壞習慣，它們涵蓋了四大類：組織代碼、團隊合作、編寫代碼以及測試和維護。
組織代碼1. 說「我稍後會改」
推遲修復代碼這個習慣不僅僅涉及到優先順序的問題。跟蹤管理問題可能會是不錯的選擇，但你需要一種方法來跟蹤小問題。有一個快捷的方法，添加 「TODO」 注釋，它能保證你不錯過任何問題。
2. 堅持一行代碼解決問題
痴迷於編寫高效、優雅的代碼是程序員的共同特點。這就像解決一個謎題——你會發現組合函數和正則表達式可以把20行代碼變成2至3行。不幸的是，這樣寫出來的代碼並不總是容易閱讀，而這通常是更應該重視的事情。先讓你的代碼可讀，然後再說技巧的事情。
3. 無意義的優化
我們常常把工作重心放在另一個錯誤的地方，就是優化。把網站減少幾個位元組的大小看起來是很不錯，但為什麼不讓 gzip 來干這個事情？需求不是更重要的事情嗎？把優化工作放在項目結束的時候，因為多數情況下需求會變化，這會讓你之前花時間進行的優化工作浪費掉。
"過早優化是萬惡之源。"
—Donald Knuth
4. 告訴自己風格問題並不是那麼重要
如果說我從多年來觀察別人的代碼學到了什麼，那就是處理編碼風格的問題是開發者最可能推遲的事情。缺乏經驗的程序員很難看到風格問題的好處，但隨著時間推移，這會越來越明顯，一旦有代碼質量出現問題，雪球效應就會讓項目變得一塌糊塗。應該嚴格要求按最佳實踐來工作，即使它們看起來微不足道。使用代碼檢查工具和靜態分析工具可以讓你從風格問題中解脫出來關注更重要的事情。
5. 把東西掃到地毯下(不被看見)
捕捉然後忽略異常，或者使用不報告錯誤的庫(比如 jQuery)，這些都是在把東西掃到地毯下的作法。如果那些錯誤中的某一個非常關鍵，那修復它將會是數倍的挑戰，因為你找不到線索，不知道從哪裡開始。避免這種事情最簡單的辦法是把這些被忽略的錯誤記錄到日誌中，這樣以後還可以研究它們。
6. 使用無意義的名稱
命名是件難事，但它是確保變數名稱和函數名稱高質的簡單方法。如果名稱中含有其它代碼不能傳遞的信息，別的開發者閱讀你的代碼時就會覺得輕鬆。命名之所以如此重要，因為名稱可以讓人對代碼所做的事情產生基本的概念。如果你需要深入計算過程去發現代碼的工作，會需要很多時間，但好的名稱可以幫助你很快理解代碼在幹什麼。
7. 忽略被證實的最佳實踐
代碼審查、測試驅動開發、質量保證、自動化部署——它們以及其它一些實踐都已經在無數項目證明了其價值所在，也正是如此，開發者們的博客在不斷的提到它們。《開發軟體：真正的工作是什麼，我們為什麼要相信它》這本書是關於最佳實踐非常不錯的參考。花點時間學習如何正確地做事情，你的開發過程就會在所有項目中得到改善，其效果會讓你大吃一驚。
8. 太早放棄計劃
不遵守計劃可以讓你的項目變得不受控制。如果你的代碼受到批評你可以說是因為計算不完整。無論如何，讓未完成的模塊結合起來一起工作將會導致緊密耦合。這種複雜的情況也會在項目領導角色發生變化時出現，如果新的領導會認為他們的方式會比架構的一致性更重要的話。
9. 堅持一個幾乎不會發生的計劃
就像放棄計劃會導致問題一樣，堅持一個行不通的計劃也是如此。因此你應該在事件變得棘手的時候向團隊分享意見，並收集反饋和意見。有時候不同的視角會改變一切。
10. 總是一個人在戰鬥
你應該努力與團隊分享你的進步和想法。有時候你認為自己在做正確的事情，其實並不是，所以不斷的交流會非常有價值。這對和你一起工作的人也會帶來好處。如果你與團隊一起討論，並指導那些驗證不足經常被卡住的成員，他們的工作通常會有所改善。
11. 拒絕寫不好的代碼
每個開發者都經歷過被最後期限逼迫著寫壞代碼的時候，其實沒什麼。你可能試圖警告客戶或者經理這會產生嚴重後果，但他們堅持原來的最後期限，所以現在只能繼續寫代碼。也許存在一個緊急的錯誤等不到你想出清晰的解決辦法。這也是為什麼程序員多才多藝是非常重要的，因為他要既能寫並不優雅的代碼，也能寫好代碼。不過希望你能重新考慮這些代碼並償還技術債務。
12. 責備別人
在開發人員和其它技術人員之間，自負是一個非常普遍的特徵，這已經不是什麼秘密了。對自己的錯誤負責是一種美德，它會讓你在同行中脫穎而出。不要害怕承認你所犯的錯誤。只有你不再害怕承認錯誤，才會輕鬆地專註於研究為什麼會出錯，以及如何避免這種錯誤再次發生。如果你連錯誤都不能承認，何談學習？
13. 不與團隊分享你學到的東西
你作為一個開發者的價值不僅存在於你寫的代碼中，還存在於你在寫代碼的時候學到了什麼。分享你的經驗，寫下相關的評論，讓其他人知道為什麼事情是這樣的，並幫助他們了解項目中難以理解的新事務。
14. 不及時向經理/客戶的反饋
工匠精神最有價值的一點是儘可能讓所有人在同一層面工作。這樣做並不是因為管理者需要填寫電子表格。這也是為了你自己：這會減輕你的不安全感，減少對項目生命周期和未來的不確定性。
15. 少用 Google
解決一個問題最快的辦法並不是去解決它。如果有問題，上 Google。當然，當然你也可以麻煩坐你旁邊的工程師，但他可能很少會給出像 Stack Overflow 上那樣詳細的解釋，更不用說你這樣做會打斷他的工作。
16. 高估你的個人風格
始終協調自己的工作風格和工作環境與團隊保持一致。理想情況下，團隊中的每個人都應該工作在類似的環境，遵從相同的代碼風格。用你自己的方式來做事情可能會更有意思，但同事可能會不習慣你的代碼風格。如果你的風格不同尋常，那別的開發者就很難接手你的工作。
17. 為代碼綁上個人的標籤
如果某人評論你的代碼，不要認為這是私事。你的代碼應該經得住考驗；也就是說，你應該能解決為什麼這樣寫。如果代碼需要改進，那是因為代碼需要改進，而不是因為你。
編寫代碼18. 不知道如何優化
良好而正確的優化策略需要經驗的積累。這產生了探索、分析和了解每個系統的過程中。讓自己知道這些事情，學習演算法的複雜度、資料庫查詢評估、協議以及一般情況下如何衡量性能。
19. 使用錯誤的工具來工作
你所知有限，但讓你保持學習的原因是新問題會引出不同的上下文，需要不同的工具——適用於當前任務的工作。以開放的心態面對新的庫和語言。不要總是根據自已經知道的事情來做決定。
20. 不想分散精力去掌握工具和 IDE
在使用工具的過程中不斷學習新的熱鍵、快捷方式或參數，可以提高你編碼的速度和認知。這與使用熱鍵來節約幾秒種時間無關，它會降低你上下文切換的頻率。你花在每個小動作上的時間越多，花在考慮問題(為什麼這麼做，接下來該幹什麼)上的時間就越少。掌握捷徑會讓你恍然大悟。
21. 忽略錯誤消息
