開發(fā)人員在自己的職業(yè)生涯、學習經(jīng)歷中，都會“開發(fā)”出一些壞習慣。在這篇文章中，作者向讀者展示他自己有或是老也改不了的壞習慣。他希望如果你剛開始這份事業(yè)，能夠避免這些壞習慣；如果你已經(jīng)有了這些毛病，那希望你能夠意識到它們，并可以開始改變。

　　1.拒絕尋求幫助

　　這一條在學習和工作場景中都很常見。我們很多人都不尋求幫助。原因很多，但我認為最主要的原因無非是自尊以及害怕讓人認為自己啥也不會。我們很多人都有冒名頂替綜合征，覺得自己不完全勝任自己的工作。我在公司里、在和客戶打交道時、甚至在上課和輔導中都有這種感覺。我們認為尋求幫助會強化這種感覺。但事實上，它浪費了大量時間，阻礙了你的成長。

　　其他真正的開發(fā)人員們都是視頻或書籍一般的資源，甚至要比這些好太多。他們可以直接回答你的問題，幫助你真正的理解它。

　　只有混蛋才會因為你問問題而批評你，這時候我會盡力避開這些人。

　　如果你想要自己找到答案，不想尋求幫助，那也沒問題，給自己一個時間限制。當你的前輩就在你旁邊，他可能知道或至少可以幫到你的時候，千萬不要浪費幾天時間來尋找答案。

　　2.20個要點，列出錯誤郵件，功能要求又有什么不一樣的商品是一個問題。他們常常導致的指控，”你為什么不修$XY，當我指出五周前？“在你的頭的發(fā)展是不是能夠鉆這些獨白到可行的票，你可能忘記的事情。不是說所有事情你媽媽沒有教你，試圖教育你的客戶或管理者如何使用bug跟蹤系統(tǒng)，或者項目管理工具，這樣你既節(jié)省時間發(fā)送無數(shù)冗長的電子郵件，他們會有一個更好的查看你目前的工作。

　　3.這一條更多地是一種技術(shù)習慣，但也可能意味著很多事情。你應當以一種直觀、高效、安全的方式寫代碼。這在自學的時候簡直太難了，因為在相關的課程中，你學到的不是寫某些代碼的最佳方法，而是導師認為這么寫最容易理解一些核心概念。所以，你必須進行一些額外的研究，找出清理你代碼的最佳方法。

　　我絕對建議你使用“避免重復代碼原則”（DRY principle，don’t repeat yourself）。如果你遇到常見的代碼塊，那就創(chuàng)建某種“類”（class）或“函數(shù)”（function）來合并這部分功能，而不是僅僅重復它。這讓代碼更加簡潔，節(jié)省了大量代碼行，并且便于他人使用。

　　你也要注意性能，比如壓縮圖片、縮小JavaScript和CSS。你可以使用task runner（如gulp）或其他工具自動完成壓縮，面對小型任務，你甚至可以使用minifier.org等手動完成。

　　4.戰(zhàn)爭的結(jié)束

　　分裂你的團隊，你的發(fā)展固定部分是一個壞主意，居然不敏捷（別擔心，我們不習慣用這個詞）。分離的前端和后端”導致“grabenk?mpfe”（或：戰(zhàn)爭的結(jié)束），這是–毫不奇怪–不是偉大的團隊精神。前端開發(fā)者會抱怨“后端的變化需要很長時間”，而后端的開發(fā)者會抱怨“第五改變API在今年“。

　　5.不能從錯誤中吸取教訓

　　作為一位開發(fā)人員，你會犯很多錯誤，這不可避免也沒什么大不了的。但如果你總是犯同樣的錯誤，不能從中吸取教訓，那就有問題了。

　　當你犯錯后，我建議你遵從這樣一個流程：

　　找出錯誤的根本原因是什么；

　　找到可以防止錯誤再次出現(xiàn)的流程；

　　弄清楚如果早先發(fā)現(xiàn)了錯誤，能否避免后果。

　　建設性的批評是學習的絕佳資源，因為建設性的批評很有針對性，是你現(xiàn)有的問題，是他人給你的具體解決方案，這是無價的。事實上，代碼審查簡直太棒了，你可以得到其他人的建議，改進你的代碼甚至是你自己。

　　所以不要把這類事情都看成人身攻擊，除非你真的受到了攻擊，或是故意的取笑和不尊重。聽進別人的批評或改進建議總是很難，但最終，這會讓你成為一個更棒的開發(fā)者。

　　無論是新開發(fā)人員，還是經(jīng)驗豐富的老手，我都希望這些建議能夠幫助到你們。