壞習慣很難改變，如果你不知道你的壞習慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經來這裡看了，不是嗎？  

作為一個程式設計師，我看到很多不好的做法，不僅僅與程式碼相關，還包括團隊合作能力。我自己曾經就有不少這些壞習慣。這裡是我認為最糟糕的 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. 忽略錯誤訊息

在沒有閱讀錯誤訊息之前，不要假設你知道程式碼有什麼問題，也不要假設你會很快發現問題所在。掌握更多關於問題的資訊總不是壞事，長遠來看，花時間收集這些資訊會更節約時間。

22. 誇大你的開發工具包

有時候你首選的編輯器或命令列工具並非解決手頭工作最好的工具。Visual Studio 是個非常不錯的 IDE，Sublime 則非常適用於動態語言，Eclipse 與 Java 更配，等等。你可能比較喜歡 Vim 或者 Emacs，但並不表示它們適用於每項工作。

23. 在程式碼中直接使用值而不使用配置

思考變化以及如何處理變化是件長期的事情。如果你不把隨時變動的碎片從工作中剝離出來，技術債務就會以驚人的速度增長。應該在適當的地方使用常量和配置檔案。

24. 總是重新發明輪子

不要寫你不需要的程式碼。也許別人已經花了大量的時間在你遇到的問題上，他或者她可能已經有一個通過測試的解決方案，你可以重用這些方案，少給自己找麻煩。

25. 盲目複製/程式碼

你在重用一段程式碼前應該搞懂它。有時候你不能在第一次看程式碼馬上就注意到它乾的所有事情。你應該花點時間仔細閱讀程式碼同時深入研究要解決的問題。

26. 不花時間去研究事務是如何工作的

通過思考事務如何工作，以及它們潛在的問題，抓住機會擴大自己的知識面。你現在可能節約了時間，免受干擾，但長遠來看，從專案中學到的東西會比現在做的更重要。

27. 對自己的程式碼過於自信

只因為是你自己寫的東西，就是一級棒，這種假設非常危險。學習更多關於程式設計的知識，就像新的工作任務那樣，從中獲取經驗。所以，看看你以前寫的程式碼，反思，並獲得進步。

28. 不權衡每個設計，解決方案，或庫

每個產品都存在優點，你只能通過使用和分析來進行了解。看一個庫和幾個用法示例不會讓你掌握它，也不是說任何情況下它都可以完善適用於你的專案。辯證的看待你所使用的每個事物。

29. 卡住時不尋求幫助

保持簡短的反饋迴圈並如你所想的那麼痛苦。尋找幫助並不代表你無能。人們會看到你的獨立，承認無知可以驅動學習，這是美德。

 測試和維護 

30. 寫可以通過的測試

寫你明知可以通過的測試是有必要的。它們會在專案重構或重新組織的時候保證其質量。但另一方面，你也必須寫明知不能通過的測試。它們可以推進專案並跟蹤問題。

31. 不顧關鍵用例的效能測試

在專案開發的中間節點建設一個自動化的效能設定，這樣在專案逐步擴大的時候才能確保沒有效能問題。

32. 不檢查構建工作

構建通過但構建結果卻不能工作這種情況很少發生，但它確實會發生。而且，你拖延著不去調查這個問題的話，時間越長，就越難以修復。構建之後進行快速測試是個很重要的習慣。

33. 最後推送大量改動或推送大量改動之後就離開

可能這是因為你過度自信，直到多次引火上身之後才學會不這樣做。請現在就接受我的建議，當構建失敗的時候你就在旁邊。

34. 與自己的程式碼斷開聯絡

對自己寫的程式碼提供支援。你是最瞭解這個程式碼而且最可能為別人提供相關幫助的人。你應該努力使自己的程式碼在多年後仍然能被自己或者別人看懂。

35. 忽略非功能性需求

釋出的時候通常很容易忘記一些重要的領域，比如效能和安全性。應該有這一個清單記錄著這些事情。你肯定不希望因為在制定最後期限的時候忘了這些非功能性需求而破壞你的聚會。