開(kāi)發人員(yuán)在自己的職業生(shēng)涯、學習經曆中(zhōng)，都會“開(kāi)發”出一(yī)些壞習慣。在這篇文章中(zhōng)，作者向讀者展示他自己有或是老也改不了的壞習慣。他希望如果你剛開(kāi)始這份事業，能夠避免這些壞習慣；如果你已經有了這些毛病，那希望你能夠意識到它們，并可以開(kāi)始改變。
1.拒絕尋求幫助
這一(yī)條在學習和工(gōng)作場景中(zhōng)都很常見。我(wǒ)們很多人都不尋求幫助。原因很多，但我(wǒ)認爲最主要的原因無非是自尊以及害怕讓人認爲自己啥也不會。我(wǒ)們很多人都有冒名頂替綜合征，覺得自己不完全勝任自己的工(gōng)作。我(wǒ)在公司裏、在和客戶打交道時、甚至在上課和輔導中(zhōng)都有這種感覺。我(wǒ)們認爲尋求幫助會強化這種感覺。但事實上，它浪費(fèi)了大(dà)量時間，阻礙了你的成長。
其他真正的開(kāi)發人員(yuán)們都是視頻(pín)或書(shū)籍一(yī)般的資(zī)源，甚至要比這些好太多。他們可以直接回答你的問題，幫助你真正的理解它。
隻有混蛋才會因爲你問問題而批評你，這時候我(wǒ)會盡力避開(kāi)這些人。
如果你想要自己找到答案，不想尋求幫助，那也沒問題，給自己一(yī)個時間限制。當你的前輩就在你旁邊，他可能知(zhī)道或至少可以幫到你的時候，千萬不要浪費(fèi)幾天時間來尋找答案。
2.20個要點，列出錯誤郵件，功能要求又(yòu)有什麽不一(yī)樣的商(shāng)品是一(yī)個問題。他們常常導緻的指控，”你爲什麽不修$XY，當我(wǒ)指出五周前？“在你的頭的發展是不是能夠鑽這些獨白(bái)到可行的票(piào)，你可能忘記的事情。不是說所有事情你媽媽沒有教你，試圖教育你的客戶或管理者如何使用bug跟蹤系統，或者項目管理工(gōng)具，這樣你既節省時間發送無數冗長的電(diàn)子郵件，他們會有一(yī)個更好的查看你目前的工(gōng)作。
3.這一(yī)條更多地是一(yī)種技術習慣，但也可能意味着很多事情。你應當以一(yī)種直觀、高效、安全的方式寫代碼。這在自學的時候簡直太難了，因爲在相關的課程中(zhōng)，你學到的不是寫某些代碼的最佳方法，而是導師認爲這麽寫最容易理解一(yī)些核心概念。所以，你必須進行一(yī)些額外(wài)的研究，找出清理你代碼的最佳方法。
我(wǒ)絕對建議你使用“避免重複代碼原則”（DRY principle，don’t repeat yourself）。如果你遇到常見的代碼塊，那就創建某種“類”（class）或“函數”（function）來合并這部分(fēn)功能，而不是僅僅重複它。這讓代碼更加簡潔，節省了大(dà)量代碼行，并且便于他人使用。
你也要注意性能，比如壓縮圖片、縮小(xiǎo)JavaScript和CSS。你可以使用task runner（如gulp）或其他工(gōng)具自動完成壓縮，面對小(xiǎo)型任務，你甚至可以使用minifier.org等手動完成。
4.戰争的結束
分(fēn)裂你的團隊，你的發展固定部分(fēn)是一(yī)個壞主意，居然不敏捷（别擔心，我(wǒ)們不習慣用這個詞）。分(fēn)離(lí)的前端和後端”導緻“grabenkämpfe”（或：戰争的結束），這是–毫不奇怪–不是偉大(dà)的團隊精神。前端開(kāi)發者會抱怨“後端的變化需要很長時間”，而後端的開(kāi)發者會抱怨“第五改變API在今年“。
5.不能從錯誤中(zhōng)吸取教訓
作爲一(yī)位開(kāi)發人員(yuán)，你會犯很多錯誤，這不可避免也沒什麽大(dà)不了的。但如果你總是犯同樣的錯誤，不能從中(zhōng)吸取教訓，那就有問題了。
當你犯錯後，我(wǒ)建議你遵從這樣一(yī)個流程：
找出錯誤的根本原因是什麽；
找到可以防止錯誤再次出現的流程；
弄清楚如果早先發現了錯誤，能否避免後果。
建設性的批評是學習的絕佳資(zī)源，因爲建設性的批評很有針對性，是你現有的問題，是他人給你的具體(tǐ)解決方案，這是無價的。事實上，代碼審查簡直太棒了，你可以得到其他人的建議，改進你的代碼甚至是你自己。
所以不要把這類事情都看成人身攻擊，除非你真的受到了攻擊，或是故意的取笑和不尊重。聽(tīng)進别人的批評或改進建議總是很難，但最終，這會讓你成爲一(yī)個更棒的開(kāi)發者。
無論是新開(kāi)發人員(yuán)，還是經驗豐富的老手，我(wǒ)都希望這些建議能夠幫助到你們。
