壞習(xí)慣很難改變，如果你不知道你的壞習(xí)慣正在影響工作，那就更難。如果你知道，但不在乎——這是最糟糕的情況。但好在你已經(jīng)來(lái)這里看了，不是嗎？

作為一個(gè)程序員，我看到很多不好的做法，不僅僅與代碼相關(guān)，還包括團(tuán)隊(duì)合作能力。我自己曾經(jīng)就有不少這些壞習(xí)慣。這里是我認(rèn)為最糟糕的 35 個(gè)壞習(xí)慣，它們涵蓋了四大類(lèi)：組織代碼、團(tuán)隊(duì)合作、編寫(xiě)代碼以及測(cè)試和維護(hù)。

組織代碼

1. 說(shuō)“我稍后會(huì)改”

推遲修復(fù)代碼這個(gè)習(xí)慣不僅僅涉及到優(yōu)先級(jí)的問(wèn)題。跟蹤管理問(wèn)題可能會(huì)是不錯(cuò)的選擇，但你需要一種方法來(lái)跟蹤小問(wèn)題。有一個(gè)快捷的方法，添加 “TODO” 注釋?zhuān)鼙ＷC你不錯(cuò)過(guò)任何問(wèn)題。

2. 堅(jiān)持一行代碼解決問(wèn)題

癡迷于編寫(xiě)高效、優(yōu)雅的代碼是程序員的共同特點(diǎn)。這就像解決一個(gè)謎題——你會(huì)發(fā)現(xiàn)組合函數(shù)和正則表達(dá)式可以把20行代碼變成2至3行。不幸的是，這樣寫(xiě)出來(lái)的代碼并不總是容易閱讀，而這通常是更應(yīng)該重視的事情。先讓你的代碼可讀，然后再說(shuō)技巧的事情。

3. 無(wú)意義的優(yōu)化

我們常常把工作重心放在另一個(gè)錯(cuò)誤的地方，就是優(yōu)化。把網(wǎng)站減少幾個(gè)字節(jié)的大小看起來(lái)是很不錯(cuò)，但為什么不讓 gzip 來(lái)干這個(gè)事情？需求不是更重要的事情嗎？把優(yōu)化工作放在項(xiàng)目結(jié)束的時(shí)候，因?yàn)槎鄶?shù)情況下需求會(huì)變化，這會(huì)讓你之前花時(shí)間進(jìn)行的優(yōu)化工作浪費(fèi)掉。

“過(guò)早優(yōu)化是萬(wàn)惡之源?！?br/>—Donald Knuth

4. 告訴自己風(fēng)格問(wèn)題并不是那么重要

如果說(shuō)我從多年來(lái)觀察別人的代碼學(xué)到了什么，那就是處理編碼風(fēng)格的問(wèn)題是開(kāi)發(fā)者最可能推遲的事情。缺乏經(jīng)驗(yàn)的程序員很難看到風(fēng)格問(wèn)題的好處，但隨著時(shí)間推移，這會(huì)越來(lái)越明顯，一旦有代碼質(zhì)量出現(xiàn)問(wèn)題，雪球效應(yīng)就會(huì)讓項(xiàng)目變得一塌糊涂。應(yīng)該嚴(yán)格要求按最佳實(shí)踐來(lái)工作，即使它們看起來(lái)微不足道。使用代碼檢查工具和靜態(tài)分析工具可以讓你從風(fēng)格問(wèn)題中解脫出來(lái)關(guān)注更重要的事情。

5. 把東西掃到地毯下(不被看見(jiàn))

捕捉然后忽略異常，或者使用不報(bào)告錯(cuò)誤的庫(kù)(比如 jQuery)，這些都是在把東西掃到地毯下的作法。如果那些錯(cuò)誤中的某一個(gè)非常關(guān)鍵，那修復(fù)它將會(huì)是數(shù)倍的挑戰(zhàn)，因?yàn)槟阏也坏骄€索，不知道從哪里開(kāi)始。避免這種事情最簡(jiǎn)單的辦法是把這些被忽略的錯(cuò)誤記錄到日志中，這樣以后還可以研究它們。

6. 使用無(wú)意義的名稱(chēng)

命名是件難事，但它是確保變量名稱(chēng)和函數(shù)名稱(chēng)高質(zhì)的簡(jiǎn)單方法。如果名稱(chēng)中含有其它代碼不能傳遞的信息，別的開(kāi)發(fā)者閱讀你的代碼時(shí)就會(huì)覺(jué)得輕松。命名之所以如此重要，因?yàn)槊Q(chēng)可以讓人對(duì)代碼所做的事情產(chǎn)生基本的概念。如果你需要深入計(jì)算過(guò)程去發(fā)現(xiàn)代碼的工作，會(huì)需要很多時(shí)間，但好的名稱(chēng)可以幫助你很快理解代碼在干什么。

7. 忽略被證實(shí)的最佳實(shí)踐

代碼審查、測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、質(zhì)量保證、自動(dòng)化部署——它們以及其它一些實(shí)踐都已經(jīng)在無(wú)數(shù)項(xiàng)目證明了其價(jià)值所在，也正是如此，開(kāi)發(fā)者們的博客在不斷的提到它們?！堕_(kāi)發(fā)軟件：真正的工作是什么，我們?yōu)槭裁匆嘈潘愤@本書(shū)是關(guān)于最佳實(shí)踐非常不錯(cuò)的參考?；c(diǎn)時(shí)間學(xué)習(xí)如何正確地做事情，你的開(kāi)發(fā)過(guò)程就會(huì)在所有項(xiàng)目中得到改善，其效果會(huì)讓你大吃一驚。

協(xié)作

8. 太早放棄計(jì)劃

不遵守計(jì)劃可以讓你的項(xiàng)目變得不受控制。如果你的代碼受到批評(píng)你可以說(shuō)是因?yàn)橛?jì)算不完整。無(wú)論如何，讓未完成的模塊結(jié)合起來(lái)一起工作將會(huì)導(dǎo)致緊密耦合。這種復(fù)雜的情況也會(huì)在項(xiàng)目領(lǐng)導(dǎo)角色發(fā)生變化時(shí)出現(xiàn)，如果新的領(lǐng)導(dǎo)會(huì)認(rèn)為他們的方式會(huì)比架構(gòu)的一致性更重要的話。

9. 堅(jiān)持一個(gè)幾乎不會(huì)發(fā)生的計(jì)劃

就像放棄計(jì)劃會(huì)導(dǎo)致問(wèn)題一樣，堅(jiān)持一個(gè)行不通的計(jì)劃也是如此。因此你應(yīng)該在事件變得棘手的時(shí)候向團(tuán)隊(duì)分享意見(jiàn)，并收集反饋和意見(jiàn)。有時(shí)候不同的視角會(huì)改變一切。

10. 總是一個(gè)人在戰(zhàn)斗

你應(yīng)該努力與團(tuán)隊(duì)分享你的進(jìn)步和想法。有時(shí)候你認(rèn)為自己在做正確的事情，其實(shí)并不是，所以不斷的交流會(huì)非常有價(jià)值。這對(duì)和你一起工作的人也會(huì)帶來(lái)好處。如果你與團(tuán)隊(duì)一起討論，并指導(dǎo)那些驗(yàn)證不足經(jīng)常被卡住的成員，他們的工作通常會(huì)有所改善。

11. 拒絕寫(xiě)不好的代碼

每個(gè)開(kāi)發(fā)者都經(jīng)歷過(guò)被最后期限逼迫著寫(xiě)壞代碼的時(shí)候，其實(shí)沒(méi)什么。你可能試圖警告客戶(hù)或者經(jīng)理這會(huì)產(chǎn)生嚴(yán)重后果，但他們堅(jiān)持原來(lái)的最后期限，所以現(xiàn)在只能繼續(xù)寫(xiě)代碼。也許存在一個(gè)緊急的錯(cuò)誤等不到你想出清晰的解決辦法。這也是為什么程序員多才多藝是非常重要的，因?yàn)樗饶軐?xiě)并不優(yōu)雅的代碼，也能寫(xiě)好代碼。不過(guò)希望你能重新考慮這些代碼并償還技術(shù)債務(wù)。

12. 責(zé)備別人

在開(kāi)發(fā)人員和其它技術(shù)人員之間，自負(fù)是一個(gè)非常普遍的特征，這已經(jīng)不是什么秘密了。對(duì)自己的錯(cuò)誤負(fù)責(zé)是一種美德，它會(huì)讓你在同行中脫穎而出。不要害怕承認(rèn)你所犯的錯(cuò)誤。只有你不再害怕承認(rèn)錯(cuò)誤，才會(huì)輕松地專(zhuān)注于研究為什么會(huì)出錯(cuò)，以及如何避免這種錯(cuò)誤再次發(fā)生。如果你連錯(cuò)誤都不能承認(rèn)，何談學(xué)習(xí)？

13. 不與團(tuán)隊(duì)分享你學(xué)到的東西

你作為一個(gè)開(kāi)發(fā)者的價(jià)值不僅存在于你寫(xiě)的代碼中，還存在于你在寫(xiě)代碼的時(shí)候?qū)W到了什么。分享你的經(jīng)驗(yàn)，寫(xiě)下相關(guān)的評(píng)論，讓其他人知道為什么事情是這樣的，并幫助他們了解項(xiàng)目中難以理解的新事務(wù)。

14. 不及時(shí)向經(jīng)理/客戶(hù)的反饋

工匠精神最有價(jià)值的一點(diǎn)是盡可能讓所有人在同一層面工作。這樣做并不是因?yàn)楣芾碚咝枰顚?xiě)電子表格。這也是為了你自己：這會(huì)減輕你的不安全感，減少對(duì)項(xiàng)目生命周期和未來(lái)的不確定性。

15. 少用 Google

解決一個(gè)問(wèn)題最快的辦法并不是去解決它。如果有問(wèn)題，上 Google。當(dāng)然，當(dāng)然你也可以麻煩坐你旁邊的工程師，但他可能很少會(huì)給出像 Stack Overflow 上那樣詳細(xì)的解釋?zhuān)挥谜f(shuō)你這樣做會(huì)打斷他的工作。

16. 高估你的個(gè)人風(fēng)格

始終協(xié)調(diào)自己的工作風(fēng)格和工作環(huán)境與團(tuán)隊(duì)保持一致。理想情況下，團(tuán)隊(duì)中的每個(gè)人都應(yīng)該工作在類(lèi)似的環(huán)境，遵從相同的代碼風(fēng)格。用你自己的方式來(lái)做事情可能會(huì)更有意思，但同事可能會(huì)不習(xí)慣你的代碼風(fēng)格。如果你的風(fēng)格不同尋常，那別的開(kāi)發(fā)者就很難接手你的工作。

17. 為代碼綁上個(gè)人的標(biāo)簽

如果某人評(píng)論你的代碼，不要認(rèn)為這是私事。你的代碼應(yīng)該經(jīng)得住考驗(yàn)；也就是說(shuō)，你應(yīng)該能解決為什么這樣寫(xiě)。如果代碼需要改進(jìn)，那是因?yàn)榇a需要改進(jìn)，而不是因?yàn)槟恪?/p>

編寫(xiě)代碼

18. 不知道如何優(yōu)化

良好而正確的優(yōu)化策略需要經(jīng)驗(yàn)的積累。這產(chǎn)生了探索、分析和了解每個(gè)系統(tǒng)的過(guò)程中。讓自己知道這些事情，學(xué)習(xí)算法的復(fù)雜度、數(shù)據(jù)庫(kù)查詢(xún)?cè)u(píng)估、協(xié)議以及一般情況下如何衡量性能。

19. 使用錯(cuò)誤的工具來(lái)工作

你所知有限，但讓你保持學(xué)習(xí)的原因是新問(wèn)題會(huì)引出不同的上下文，需要不同的工具——適用于當(dāng)前任務(wù)的工作。以開(kāi)放的心態(tài)面對(duì)新的庫(kù)和語(yǔ)言。不要總是根據(jù)自已經(jīng)知道的事情來(lái)做決定。

20. 不想分散精力去掌握工具和 IDE

在使用工具的過(guò)程中不斷學(xué)習(xí)新的熱鍵、快捷方式或參數(shù)，可以提高你編碼的速度和認(rèn)知。這與使用熱鍵來(lái)節(jié)約幾秒種時(shí)間無(wú)關(guān)，它會(huì)降低你上下文切換的頻率。你花在每個(gè)小動(dòng)作上的時(shí)間越多，花在考慮問(wèn)題(為什么這么做，接下來(lái)該干什么)上的時(shí)間就越少。掌握捷徑會(huì)讓你恍然大悟。

21. 忽略錯(cuò)誤消息

在沒(méi)有閱讀錯(cuò)誤消息之前，不要假設(shè)你知道代碼有什么問(wèn)題，也不要假設(shè)你會(huì)很快發(fā)現(xiàn)問(wèn)題所在。掌握更多關(guān)于問(wèn)題的信息總不是壞事，長(zhǎng)遠(yuǎn)來(lái)看，花時(shí)間收集這些信息會(huì)更節(jié)約時(shí)間。

22. 夸大你的開(kāi)發(fā)工具包

有時(shí)候你首選的編輯器或命令行工具并非解決手頭工作最好的工具。Visual Studio 是個(gè)非常不錯(cuò)的 IDE，Sublime 則非常適用于動(dòng)態(tài)語(yǔ)言，Eclipse 與 Java 更配，等等。你可能比較喜歡 Vim 或者 Emacs，但并不表示它們適用于每項(xiàng)工作。

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

思考變化以及如何處理變化是件長(zhǎng)期的事情。如果你不把隨時(shí)變動(dòng)的碎片從工作中剝離出來(lái)，技術(shù)債務(wù)就會(huì)以驚人的速度增長(zhǎng)。應(yīng)該在適當(dāng)?shù)牡胤绞褂贸Ａ亢团渲梦募?/p>

24. 總是重新發(fā)明輪子

不要寫(xiě)你不需要的代碼。也許別人已經(jīng)花了大量的時(shí)間在你遇到的問(wèn)題上，他或者她可能已經(jīng)有一個(gè)通過(guò)測(cè)試的解決方案，你可以重用這些方案，少給自己找麻煩。

25. 盲目復(fù)制/代碼

你在重用一段代碼前應(yīng)該搞懂它。有時(shí)候你不能在第一次看代碼馬上就注意到它干的所有事情。你應(yīng)該花點(diǎn)時(shí)間仔細(xì)閱讀代碼同時(shí)深入研究要解決的問(wèn)題。

26. 不花時(shí)間去研究事務(wù)是如何工作的

通過(guò)思考事務(wù)如何工作，以及它們潛在的問(wèn)題，抓住機(jī)會(huì)擴(kuò)大自己的知識(shí)面。你現(xiàn)在可能節(jié)約了時(shí)間，免受干擾，但長(zhǎng)遠(yuǎn)來(lái)看，從項(xiàng)目中學(xué)到的東西會(huì)比現(xiàn)在做的更重要。

27. 對(duì)自己的代碼過(guò)于自信

只因?yàn)槭悄阕约簩?xiě)的東西，就是一級(jí)棒，這種假設(shè)非常危險(xiǎn)。學(xué)習(xí)更多關(guān)于編程的知識(shí)，就像新的工作任務(wù)那樣，從中獲取經(jīng)驗(yàn)。所以，看看你以前寫(xiě)的代碼，反思，并獲得進(jìn)步。

28. 不權(quán)衡每個(gè)設(shè)計(jì)，解決方案，或庫(kù)

每個(gè)產(chǎn)品都存在優(yōu)點(diǎn)，你只能通過(guò)使用和分析來(lái)進(jìn)行了解。看一個(gè)庫(kù)和幾個(gè)用法示例不會(huì)讓你掌握它，也不是說(shuō)任何情況下它都可以完善適用于你的項(xiàng)目。辯證的看待你所使用的每個(gè)事物。

29. 卡住時(shí)不尋求幫助

保持簡(jiǎn)短的反饋循環(huán)并如你所想的那么痛苦。尋找?guī)椭⒉淮砟銦o(wú)能。人們會(huì)看到你的獨(dú)立，承認(rèn)無(wú)知可以驅(qū)動(dòng)學(xué)習(xí)，這是美德。

測(cè)試和維護(hù)

30. 寫(xiě)可以通過(guò)的測(cè)試

寫(xiě)你明知可以通過(guò)的測(cè)試是有必要的。它們會(huì)在項(xiàng)目重構(gòu)或重新組織的時(shí)候保證其質(zhì)量。但另一方面，你也必須寫(xiě)明知不能通過(guò)的測(cè)試。它們可以推進(jìn)項(xiàng)目并跟蹤問(wèn)題。

31. 不顧關(guān)鍵用例的性能測(cè)試

在項(xiàng)目開(kāi)發(fā)的中間節(jié)點(diǎn)建設(shè)一個(gè)自動(dòng)化的性能設(shè)置，這樣在項(xiàng)目逐步擴(kuò)大的時(shí)候才能確保沒(méi)有性能問(wèn)題。

32. 不檢查構(gòu)建工作

構(gòu)建通過(guò)但構(gòu)建結(jié)果卻不能工作這種情況很少發(fā)生，但它確實(shí)會(huì)發(fā)生。而且，你拖延著不去調(diào)查這個(gè)問(wèn)題的話，時(shí)間越長(zhǎng)，就越難以修復(fù)。構(gòu)建之后進(jìn)行快速測(cè)試是個(gè)很重要的習(xí)慣。

33. 最后推送大量改動(dòng)或推送大量改動(dòng)之后就離開(kāi)

可能這是因?yàn)槟氵^(guò)度自信，直到多次引火上身之后才學(xué)會(huì)不這樣做。請(qǐng)現(xiàn)在就接受我的建議，當(dāng)構(gòu)建失敗的時(shí)候你就在旁邊。

34. 與自己的代碼斷開(kāi)聯(lián)系

對(duì)自己寫(xiě)的代碼提供支持。你是最了解這個(gè)代碼而且最可能為別人提供相關(guān)幫助的人。你應(yīng)該努力使自己的代碼在多年后仍然能被自己或者別人看懂。

35. 忽略非功能性需求

發(fā)布的時(shí)候通常很容易忘記一些重要的領(lǐng)域，比如性能和安全性。應(yīng)該有這一個(gè)清單記錄著這些事情。你肯定不希望因?yàn)樵谥贫ㄗ詈笃谙薜臅r(shí)候忘了這些非功能性需求而破壞你的聚會(huì)。

你有什么糟糕的編程習(xí)慣嗎？

人們常說(shuō)，我們是喜歡按部就班的生物。通過(guò)習(xí)慣來(lái)改善你的工作方式可以避免你每次遇到同樣的問(wèn)題都得去費(fèi)力思考。一旦你就做某件事情總結(jié)出并且吸收了一個(gè)不錯(cuò)的辦法，以后再來(lái)做一次的話就會(huì)毫不費(fèi)力了。