壞習慣很難改變，如果你不知道你的壞習慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經(jīng)來這里看了，不是嗎？
作為一個程序員，我看到很多不好的做法，不僅僅與代碼相關，還包括團隊合作能力。我自己曾經(jīng)就有不少這些壞習慣。這里是我認為最糟糕的 35 個壞習慣，它們涵蓋了四大類：組織代碼、團隊合作、編寫代碼以及測試和維護。
推遲修復代碼這個習慣不僅僅涉及到優(yōu)先級的問題。跟蹤管理問題可能會是不錯的選擇，但你需要一種方法來跟蹤小問題。有一個快捷的方法，添加 “TODO” 注釋，它能保證你不錯過任何問題。
癡迷于編寫高效、優(yōu)雅的代碼是程序員的共同特點。這就像解決一個謎題——你會發(fā)現(xiàn)組合函數(shù)和正則表達式可以把20行代碼變成2至3行。不幸的是，這樣寫出來的代碼并不總是容易閱讀，而這通常是更應該重視的事情。先讓你的代碼可讀，然后再說技巧的事情。
我們常常把工作重心放在另一個錯誤的地方，就是優(yōu)化。把網(wǎng)站減少幾個字節(jié)的大小看起來是很不錯，但為什么不讓 gzip 來干這個事情？需求不是更重要的事情嗎？把優(yōu)化工作放在項目結束的時候，因為多數(shù)情況下需求會變化，這會讓你之前花時間進行的優(yōu)化工作浪費掉。
“過早優(yōu)化是萬惡之源?！?br>—Donald Knuth
如果說我從多年來觀察別人的代碼學到了什么，那就是處理編碼風格的問題是開發(fā)者最可能推遲的事情。缺乏經(jīng)驗的程序員很難看到風格問題的好處，但隨著時間推移，這會越來越明顯，一旦有代碼質量出現(xiàn)問題，雪球效應就會讓項目變得一塌糊涂。應該嚴格要求按最佳實踐來工作，即使它們看起來微不足道。使用代碼檢查工具和靜態(tài)分析工具可以讓你從風格問題中解脫出來關注更重要的事情。
捕捉然后忽略異常，或者使用不報告錯誤的庫(比如 jQuery)，這些都是在把東西掃到地毯下的作法。如果那些錯誤中的某一個非常關鍵，那修復它將會是數(shù)倍的挑戰(zhàn)，因為你找不到線索，不知道從哪里開始。避免這種事情最簡單的辦法是把這些被忽略的錯誤記錄到日志中，這樣以后還可以研究它們。
命名是件難事，但它是確保變量名稱和函數(shù)名稱高質的簡單方法。如果名稱中含有其它代碼不能傳遞的信息，別的開發(fā)者閱讀你的代碼時就會覺得輕松。命名之所以如此重要，因為名稱可以讓人對代碼所做的事情產(chǎn)生基本的概念。如果你需要深入計算過程去發(fā)現(xiàn)代碼的工作，會需要很多時間，但好的名稱可以幫助你很快理解代碼在干什么。
代碼審查、測試驅動開發(fā)、質量保證、自動化部署——它們以及其它一些實踐都已經(jīng)在無數(shù)項目證明了其價值所在，也正是如此，開發(fā)者們的博客在不斷的提到它們?！堕_發(fā)軟件：真正的工作是什么，我們?yōu)槭裁匆嘈潘愤@本書是關于最佳實踐非常不錯的參考?；c時間學習如何正確地做事情，你的開發(fā)過程就會在所有項目中得到改善，其效果會讓你大吃一驚。
不遵守計劃可以讓你的項目變得不受控制。如果你的代碼受到批評你可以說是因為計算不完整。無論如何，讓未完成的模塊結合起來一起工作將會導致緊密耦合。這種復雜的情況也會在項目領導角色發(fā)生變化時出現(xiàn)，如果新的領導會認為他們的方式會比架構的一致性更重要的話。
就像放棄計劃會導致問題一樣，堅持一個行不通的計劃也是如此。因此你應該在事件變得棘手的時候向團隊分享意見，并收集反饋和意見。有時候不同的視角會改變一切。
你應該努力與團隊分享你的進步和想法。有時候你認為自己在做正確的事情，其實并不是，所以不斷的交流會非常有價值。這對和你一起工作的人也會帶來好處。如果你與團隊一起討論，并指導那些驗證不足經(jīng)常被卡住的成員，他們的工作通常會有所改善。
每個開發(fā)者都經(jīng)歷過被最后期限逼迫著寫壞代碼的時候，其實沒什么。你可能試圖警告客戶或者經(jīng)理這會產(chǎn)生嚴重后果，但他們堅持原來的最后期限，所以現(xiàn)在只能繼續(xù)寫代碼。也許存在一個緊急的錯誤等不到你想出清晰的解決辦法。這也是為什么程序員多才多藝是非常重要的，因為他要既能寫并不優(yōu)雅的代碼，也能寫好代碼。不過希望你能重新考慮這些代碼并償還技術債務。
在開發(fā)人員和其它技術人員之間，自負是一個非常普遍的特征，這已經(jīng)不是什么秘密了。對自己的錯誤負責是一種美德，它會讓你在同行中脫穎而出。不要害怕承認你所犯的錯誤。只有你不再害怕承認錯誤，才會輕松地專注于研究為什么會出錯，以及如何避免這種錯誤再次發(fā)生。如果你連錯誤都不能承認，何談學習？
你作為一個開發(fā)者的價值不僅存在于你寫的代碼中，還存在于你在寫代碼的時候學到了什么。分享你的經(jīng)驗，寫下相關的評論，讓其他人知道為什么事情是這樣的，并幫助他們了解項目中難以理解的新事務。
工匠精神最有價值的一點是盡可能讓所有人在同一層面工作。這樣做并不是因為管理者需要填寫電子表格。這也是為了你自己：這會減輕你的不安全感，減少對項目生命周期和未來的不確定性。
解決一個問題最快的辦法并不是去解決它。如果有問題，上 Google。當然，當然你也可以麻煩坐你旁邊的工程師，但他可能很少會給出像 Stack Overflow 上那樣詳細的解釋，更不用說你這樣做會打斷他的工作。
始終協(xié)調自己的工作風格和工作環(huán)境與團隊保持一致。理想情況下，團隊中的每個人都應該工作在類似的環(huán)境，遵從相同的代碼風格。用你自己的方式來做事情可能會更有意思，但同事可能會不習慣你的代碼風格。如果你的風格不同尋常，那別的開發(fā)者就很難接手你的工作。
如果某人評論你的代碼，不要認為這是私事。你的代碼應該經(jīng)得住考驗；也就是說，你應該能解決為什么這樣寫。如果代碼需要改進，那是因為代碼需要改進，而不是因為你。
良好而正確的優(yōu)化策略需要經(jīng)驗的積累。這產(chǎn)生了探索、分析和了解每個系統(tǒng)的過程中。讓自己知道這些事情，學習算法的復雜度、數(shù)據(jù)庫查詢評估、協(xié)議以及一般情況下如何衡量性能。
你所知有限，但讓你保持學習的原因是新問題會引出不同的上下文，需要不同的工具——適用于當前任務的工作。以開放的心態(tài)面對新的庫和語言。不要總是根據(jù)自已經(jīng)知道的事情來做決定。
在使用工具的過程中不斷學習新的熱鍵、快捷方式或參數(shù)，可以提高你編碼的速度和認知。這與使用熱鍵來節(jié)約幾秒種時間無關，它會降低你上下文切換的頻率。你花在每個小動作上的時間越多，花在考慮問題(為什么這么做，接下來該干什么)上的時間就越少。掌握捷徑會讓你恍然大悟。
在沒有閱讀錯誤消息之前，不要假設你知道代碼有什么問題，也不要假設你會很快發(fā)現(xiàn)問題所在。掌握更多關于問題的信息總不是壞事，長遠來看，花時間收集這些信息會更節(jié)約時間。
有時候你首選的編輯器或命令行工具并非解決手頭工作最好的工具。Visual Studio 是個非常不錯的 IDE，Sublime 則非常適用于動態(tài)語言，Eclipse 與 Java 更配，等等。你可能比較喜歡 Vim 或者 Emacs，但并不表示它們適用于每項工作。
思考變化以及如何處理變化是件長期的事情。如果你不把隨時變動的碎片從工作中剝離出來，技術債務就會以驚人的速度增長。應該在適當?shù)牡胤绞褂贸Ａ亢团渲梦募?/p>
不要寫你不需要的代碼。也許別人已經(jīng)花了大量的時間在你遇到的問題上，他或者她可能已經(jīng)有一個通過測試的解決方案，你可以重用這些方案，少給自己找麻煩。
你在重用一段代碼前應該搞懂它。有時候你不能在第一次看代碼馬上就注意到它干的所有事情。你應該花點時間仔細閱讀代碼同時深入研究要解決的問題。
通過思考事務如何工作，以及它們潛在的問題，抓住機會擴大自己的知識面。你現(xiàn)在可能節(jié)約了時間，免受干擾，但長遠來看，從項目中學到的東西會比現(xiàn)在做的更重要。
只因為是你自己寫的東西，就是一級棒，這種假設非常危險。學習更多關于編程的知識，就像新的工作任務那樣，從中獲取經(jīng)驗。所以，看看你以前寫的代碼，反思，并獲得進步。
每個產(chǎn)品都存在優(yōu)點，你只能通過使用和分析來進行了解?？匆粋€庫和幾個用法示例不會讓你掌握它，也不是說任何情況下它都可以完善適用于你的項目。辯證的看待你所使用的每個事物。
保持簡短的反饋循環(huán)并如你所想的那么痛苦。尋找?guī)椭⒉淮砟銦o能。人們會看到你的獨立，承認無知可以驅動學習，這是美德。
寫你明知可以通過的測試是有必要的。它們會在項目重構或重新組織的時候保證其質量。但另一方面，你也必須寫明知不能通過的測試。它們可以推進項目并跟蹤問題。
在項目開發(fā)的中間節(jié)點建設一個自動化的性能設置，這樣在項目逐步擴大的時候才能確保沒有性能問題。
構建通過但構建結果卻不能工作這種情況很少發(fā)生，但它確實會發(fā)生。而且，你拖延著不去調查這個問題的話，時間越長，就越難以修復。構建之后進行快速測試是個很重要的習慣。
可能這是因為你過度自信，直到多次引火上身之后才學會不這樣做。請現(xiàn)在就接受我的建議，當構建失敗的時候你就在旁邊。
對自己寫的代碼提供支持。你是最了解這個代碼而且最可能為別人提供相關幫助的人。你應該努力使自己的代碼在多年后仍然能被自己或者別人看懂。
發(fā)布的時候通常很容易忘記一些重要的領域，比如性能和安全性。應該有這一個清單記錄著這些事情。你肯定不希望因為在制定最后期限的時候忘了這些非功能性需求而破壞你的聚會。
人們常說，我們是喜歡按部就班的生物。通過習慣來改善你的工作方式可以避免你每次遇到同樣的問題都得去費力思考。一旦你就做某件事情總結出并且吸收了一個不錯的辦法，以后再來做一次的話就會毫不費力了。
