壞習慣很難改變，如果你不知道你的壞習慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經來這裏看了，不是嗎？
作爲一個程序員，我看到很多不好的做法，不僅僅與代碼相關，還包括團隊合作能力。我自己曾經就有不少這些壞習慣。這裏是我認爲最糟糕的 35 個壞習慣，它們涵蓋了四大類：組織代碼、團隊合作、編寫代碼以及測試和維護。！
組織代碼
1.說“我稍後會改”
推遲修復代碼這個習慣不僅僅涉及到優先級的問題。跟蹤管理問題可能會是不錯的選擇，但你需要一種方法來跟蹤小問題。有一個快捷的方法，添加 “TODO” 註釋，它能保證你不錯過任何問題。
2. 堅持一行代碼解決問題
癡迷於編寫高效、優雅的代碼是程序員的共同特點。這就像解決一個謎題——你會發現組合函數和正則表達式可以把20行代碼變成2至3行。不幸的是，這樣寫出來的代碼並不總是容易閱讀，而這通常是更應該重視的事情。先讓你的代碼可讀，然後再說技巧的事情。
3. 無意義的優化
我們常常把工作重心放在另一個錯誤的地方，就是優化。把網站減少幾個字節的大小看起來是很不錯，但爲什麼不讓 gzip 來幹這個事情？需求不是更重要的事情嗎？把優化工作放在項目結束的時候，因爲多數情況下需求會變化，這會讓你之前花時間進行的優化工作浪費掉。
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. 忽略非功能性需求
發佈的時候通常很容易忘記一些重要的領域，比如性能和安全性。應該有這一個清單記錄着這些事情。你肯定不希望因爲在制定最後期限的時候忘了這些非功能性需求而破壞你的聚會。
壞習慣很難改變，如果你不知道你的壞習慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經來這裏看了，不是嗎？
作爲一個程序員，我看到很多不好的做法，不僅僅與代碼相關，還包括團隊合作能力。我自己曾經就有不少這些壞習慣。這裏是我認爲最糟糕的 35 個壞習慣，它們涵蓋了四大類：組織代碼、團隊合作、編寫代碼以及測試和維護。！
組織代碼
1.說“我稍後會改”
推遲修復代碼這個習慣不僅僅涉及到優先級的問題。跟蹤管理問題可能會是不錯的選擇，但你需要一種方法來跟蹤小問題。有一個快捷的方法，添加 “TODO” 註釋，它能保證你不錯過任何問題。
2. 堅持一行代碼解決問題
癡迷於編寫高效、優雅的代碼是程序員的共同特點。這就像解決一個謎題——你會發現組合函數和正則表達式可以把20行代碼變成2至3行。不幸的是，這樣寫出來的代碼並不總是容易閱讀，而這通常是更應該重視的事情。先讓你的代碼可讀，然後再說技巧的事情。
3. 無意義的優化
我們常常把工作重心放在另一個錯誤的地方，就是優化。把網站減少幾個字節的大小看起來是很不錯，但爲什麼不讓 gzip 來幹這個事情？需求不是更重要的事情嗎？把優化工作放在項目結束的時候，因爲多數情況下需求會變化，這會讓你之前花時間進行的優化工作浪費掉。
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. 忽略非功能性需求
發佈的時候通常很容易忘記一些重要的領域，比如性能和安全性。應該有這一個清單記錄着這些事情。你肯定不希望因爲在制定最後期限的時候忘了這些非功能性需求而破壞你的聚會。