不惜一切代價要避免的35個糟糕的編程習慣
譯文【51CTO.com快譯】 每個程序員需要認識到哪些糟糕的編程方法，以便避而遠之?這個問題最初出現(xiàn)在知識共享網(wǎng)站Quora上，一些見解獨特的人士在這個網(wǎng)站上回答引人注目的問題。
The Firehose Project的首席技術官兼聯(lián)合創(chuàng)始人肯·馬扎卡(Ken Mazaika)在Quora上回答了這個問題：
有35個常見的糟糕編程習慣。
糟糕習慣可能不止這些，而這是我所能想起來的35個糟糕的編程習慣。我把最重要的兩個糟糕習慣列在第17個和第35個，因為我希望你能看好整個回答。我認為你讀后會有所收獲。
1. 搞得你好像無所不知。別犯傻了，你不可能做到無所不知。那也很正常。
2. 整天開會。如果你把大部分時間花在開會上，就應該考慮更合理地利用時間了。
3. 有人批評你的代碼時，反應過大。最優(yōu)秀的開發(fā)人員愿意抱著一種開放、坦率的心態(tài)，探討自己編寫的代碼，以及如何改進代碼。
4. 過早地放棄。太多的程序員離解決辦法只差一步，就在快要解決問題前一刻放棄。
5. 拒絕尋求幫助。通過向別人闡述自己的問題，你常常會發(fā)現(xiàn)解決辦法。這就是所謂的“小黃鴨調試法”(rubber duck debugging)。
6. 將責任推卸給他人。最可貴的開發(fā)人員敢于為自己編寫的代碼負責、并承擔責任。
7. 編寫過早優(yōu)化其他代碼的代碼。在大多數(shù)情況下，雖然全面優(yōu)化代碼可以獲得性能方面的優(yōu)勢，但是結果很難理解代碼，這是不值得的。
8. 忽視其他開發(fā)人員的意見。作為開發(fā)人員，最好的學習和成長途徑之一就是與經(jīng)驗比自己更豐富的開發(fā)人員結對編程。要樂于尋求別人的意見。
9. 不知道如何優(yōu)化代碼。有些情況下性能是個大問題，比如以下方面存在問題：
·算法復雜性
·低效的數(shù)據(jù)庫操作
·第三方的API
·N+1查詢
出現(xiàn)性能問題時，你需要知道如何分析性能問題，明白什么要花時間研究，以及如何解決這些問題。
10. 低估與團隊其他成員之間的關系。你受雇來編寫代碼。但是你也需要能夠與團隊的其他成員處理好關系。
11. 搞辦公室政治。有時候，其他開發(fā)團隊會做出你覺得不正確的決定。但是只要你能完成你團隊的目標，最好繞開其他團隊的錯誤，而不是針鋒相對。
12. 一遇到壓力，就呆若木雞。在用戶無法使用產(chǎn)品的場景下，你面臨巨大的壓力。你要養(yǎng)成保持冷靜、完成工作的能力。
13. 沒有能力編寫糟糕代碼。在現(xiàn)實世界中，需要結合下列因素做一些取舍：
·最后日期
·實驗
·需要立即修復的緊急錯誤
你要有這種心態(tài)：可以編寫糟糕代碼，以滿足眼前的需求。
14. 針對簡單問題卻采用過度設計。面對容易處理的問題，別開發(fā)讓人困惑的解決方案。
15. 行為像老板，不像領導人。太多的開發(fā)人員不知道如何管理其他人。你應該是其他開發(fā)人員尋求指導和指點的那個人，而不是僅僅下達逐步指示。
16. 使用不當?shù)墓ぞ邅硖幚砉ぷ鳌?/strong>別再根據(jù)“這是我熟悉的東西”來做決定。你需要敢于使用不同的技術、語言和框架。
17. 拒絕研究編程問題。谷歌搜索引擎是程序員的工具箱中最強大的工具之一。
18. 不好好掌握工具。由于你要花大量的時間來使用文本編輯器、命令行及編寫代碼的其他工具等工具，有必要熟練掌握。花時間學習讓你更高效的技巧和竅門。
19. 避免錯誤消息。代碼錯誤經(jīng)常發(fā)生。它們還通常包括一些很寶貴的信息，表明什么出了錯，為何會出錯，哪幾行代碼觸發(fā)了問題。你應該找出錯誤信息，而不是竭力避免錯誤信息。
20. 掰著指頭算時間。最優(yōu)秀的開發(fā)人員享受編寫代碼的時光，常常廢寢忘食、樂此不疲。哪怕你編程了10000小時，也好像一如既往地熱愛編程。
21. 拒絕從錯誤中汲取教訓。犯錯后，應當縮小范圍，明白這三個方面：
1. 犯錯的根本原因是什么?
2. 可以落實流程或行為，防止將來出現(xiàn)這種類型的錯誤嗎?
3.越早發(fā)現(xiàn)錯誤，影響就越小。
拒絕從錯誤中汲取教訓會導致你一再犯錯。
22. 害怕丟掉代碼。要知道，花三天時間編寫錯誤的解決方案會讓你更深刻地認識到如何淪為分析癱瘓(analysis paralysis)的受害者。
23. 過分偏愛自己的開發(fā)工具包。一些開發(fā)人員喜歡名為vim的文本編輯器。有些人討厭它，喜歡名為emacs的文本編輯器。但是在一些場景下，使用一種而不是另一種是明智之舉。
24. 將自己與開發(fā)者社區(qū)脫離開來。到處都有編程社區(qū)。由于Railsbridge和Girl Develop It之類的組織，以及RubyConf和RailsConf之類的活動以及其他會議，許多社區(qū)等著你去發(fā)現(xiàn)。
25. 沒有推特帳戶。Ruby、Rails、JavaScript等大型開源項目及其他工具的開發(fā)者都擁有推特帳戶。花點時間在推特上，那樣你有機會了解設計你所用軟件的那些人的想法。
26. 不回饋社區(qū)。你應該盡早擁抱編程社區(qū)。如果你這么做，會認識到編程社區(qū)有多大的幫助、多么友好。
27. 花好多時間來解決問題，并且解決了問題，卻沒有記入文檔。你經(jīng)常會遇到網(wǎng)上還沒有人解決的某個奇怪的、很具體的問題?；〞r間自行搞定后，你有必要寫帖子分享或交流，那樣就能幫助下一個遇到這個問題的人。
28. 代碼中編寫的注釋不是太多就是太少。對開發(fā)人員來說，注釋是必不可少的說明。但與凡事講究個度，注釋也應該適可而止。
29. 過于懶惰，不愿向產(chǎn)品經(jīng)理告知問題的最新情況。產(chǎn)品經(jīng)理獲得及時的最新情況，并知道產(chǎn)品的狀態(tài)(在合理范圍內(nèi))很重要。如果你不及時告知問題的最新情況，這會帶來許多頭痛的問題。
30. 經(jīng)常把無關的功能捆綁到同一個項目中。很容易養(yǎng)成把兩個無關的功能分類到同一個項目中這種陋習。如果兩個不同的系統(tǒng)規(guī)模都很大，厘清問題會來得異常復雜。
31. 與團隊的其他成員一起認真地提出合理的計劃，結果發(fā)生某個意想不到的事情后，全面放棄計劃，完全改變路線。沒有比這更糟糕的事情了。
32. 堅持執(zhí)行經(jīng)過全面考慮，卻明顯行不通的計劃。唯一比最后一刻放棄計劃更糟糕的莫過于拒絕停止執(zhí)行糟糕的主意。
33. 一再為編寫的糟糕代碼而道歉。如果你發(fā)現(xiàn)自己一再為編寫的糟糕代碼而道歉，這可能意味著你需要重新評估最后期限。
34. 沒有把精力花在進行代碼審查這項工作上。開發(fā)團隊是個整體，確保每個成員貢獻的代碼符合團隊的高標準，這是每個團隊成員義不容辭的責任。
35. 沒有花足夠的時間來輔導團隊的其他開發(fā)人員。確保你的團隊在經(jīng)常學習、成長以及提高編程能力是你應盡的工作。
我堅信，每個開發(fā)人員都在不斷完善之中。所以有這些壞習慣完全很正常，沒什么大不了。實際上，作為開發(fā)人員或其他任何類型的專業(yè)人員，提升自我的關鍵在于遵循這三個步驟：
1.承認自己有壞習慣。
2.找到改變壞習慣的動機。
3.消除壞習慣，養(yǎng)成好習慣，從而將這種動機付諸實踐。
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
