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

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

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

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

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

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

"過早優(yōu)化是萬惡之源。"
—Donald Knuth

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

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

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

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

6. 使用無意義的名稱

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

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

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

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

不遵守計(jì)劃可以讓你的項(xiàng)目變得不受控制。如果你的代碼受到批評(píng)你可以說是因?yàn)橛?jì)算不完整。無論如何，讓未完成的模塊結(jié)合起來一起工作將會(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)致問題一樣，堅(jiān)持一個(gè)行不通的計(jì)劃也是如此。因此你應(yīng)該在事件變得棘手的時(shí)候向團(tuán)隊(duì)分享意見，并收集反饋和意見。有時(shí)候不同的視角會(huì)改變一切。

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

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

11. 拒絕寫不好的代碼

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

12. 責(zé)備別人

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

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

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

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

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

15. 少用 Google

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30. 寫可以通過的測(cè)試

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

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

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

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

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

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

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

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

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

35. 忽略非功能性需求

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

轉(zhuǎn)載請(qǐng)注明出處 AE博客|墨淵 ? 35 個(gè)毀掉你代碼的不良習(xí)慣 ！