坏习惯很难改变，如果你不知道你的坏习惯正在影响工作，那就更难。如果你知道，但不在乎——这是最糟糕的情况。但好在你已经来这里看了，不是吗？  
作为一个程序员，我看到很多不好的做法，不仅仅与代码相关，还包括团队合作能力。我自己曾经就有不少这些坏习惯。这里是我认为最糟糕的 35 个坏习惯，它们涵盖了四大类：组织代码、团队合作、编写代码以及测试和维护。

组织代码

1.说“我稍后会改”

推迟修复代码这个习惯不仅仅涉及到优先级的问题。跟踪管理问题可能会是不错的选择，但你需要一种方法来跟踪小问题。有一个快捷的方法，添加 “TODO” 注释，它能保证你不错过任何问题。

2. 坚持一行代码解决问题

痴迷于编写高效、优雅的代码是程序员的共同特点。这就像解决一个谜题——你会发现组合函数和正则表达式可以把20行代码变成2至3行。不幸的是，这样写出来的代码并不总是容易阅读，而这通常是更应该重视的事情。先让你的代码可读，然后再说技巧的事情。

3. 无意义的优化

我们常常把工作重心放在另一个错误的地方，就是优化。把网站减少几个字节的大小看起来是很不错，但为什么不让 gzip 来干这个事情？需求不是更重要的事情吗？把优化工作放在项目结束的时候，因为多数情况下需求会变化，这会让你之前花时间进行的优化工作浪费掉。

"过早优化是万恶之源。"
—Donald Knuth

4. 告诉自己风格问题并不是那么重要

如果说我从多年来观察别人的代码学到了什么，那就是处理编码风格的问题是开发者最可能推迟的事情。缺乏经验的程序员很难看到风格问题的好处，但随着时间推移，这会越来越明显，一旦有代码质量出现问题，雪球效应就会让项目变得一塌糊涂。应该严格要求按最佳实践来工作，即使它们看起来微不足道。使用代码检查工具和静态分析工具可以让你从风格问题中解脱出来关注更重要的事情。

5. 把东西扫到地毯下(不被看见)

捕捉然后忽略异常，或者使用不报告错误的库(比如 jQuery)，这些都是在把东西扫到地毯下的作法。如果那些错误中的某一个非常关键，那修复它将会是数倍的挑战，因为你找不到线索，不知道从哪里开始。避免这种事情最简单的办法是把这些被忽略的错误记录到日志中，这样以后还可以研究它们。

6. 使用无意义的名称

命名是件难事，但它是确保变量名称和函数名称高质的简单方法。如果名称中含有其它代码不能传递的信息，别的开发者阅读你的代码时就会觉得轻松。命名之所以如此重要，因为名称可以让人对代码所做的事情产生基本的概念。如果你需要深入计算过程去发现代码的工作，会需要很多时间，但好的名称可以帮助你很快理解代码在干什么。

7. 忽略被证实的最佳实践

代码审查、测试驱动开发、质量保证、自动化部署——它们以及其它一些实践都已经在无数项目证明了其价值所在，也正是如此，开发者们的博客在不断的提到它们。《开发软件：真正的工作是什么，我们为什么要相信它》这本书是关于最佳实践非常不错的参考。花点时间学习如何正确地做事情，你的开发过程就会在所有项目中得到改善，其效果会让你大吃一惊。

协作

8. 太早放弃计划

不遵守计划可以让你的项目变得不受控制。如果你的代码受到批评你可以说是因为计算不完整。无论如何，让未完成的模块结合起来一起工作将会导致紧密耦合。这种复杂的情况也会在项目领导角色发生变化时出现，如果新的领导会认为他们的方式会比架构的一致性更重要的话。

9. 坚持一个几乎不会发生的计划

就像放弃计划会导致问题一样，坚持一个行不通的计划也是如此。因此你应该在事件变得棘手的时候向团队分享意见，并收集反馈和意见。有时候不同的视角会改变一切。

10. 总是一个人在战斗

你应该努力与团队分享你的进步和想法。有时候你认为自己在做正确的事情，其实并不是，所以不断的交流会非常有价值。这对和你一起工作的人也会带来好处。如果你与团队一起讨论，并指导那些验证不足经常被卡住的成员，他们的工作通常会有所改善。

11. 拒绝写不好的代码

每个开发者都经历过被最后期限逼迫着写坏代码的时候，其实没什么。你可能试图警告客户或者经理这会产生严重后果，但他们坚持原来的最后期限，所以现在只能继续写代码。也许存在一个紧急的错误等不到你想出清晰的解决办法。这也是为什么程序员多才多艺是非常重要的，因为他要既能写并不优雅的代码，也能写好代码。不过希望你能重新考虑这些代码并偿还技术债务。

12. 责备别人

在开发人员和其它技术人员之间，自负是一个非常普遍的特征，这已经不是什么秘密了。对自己的错误负责是一种美德，它会让你在同行中脱颖而出。不要害怕承认你所犯的错误。只有你不再害怕承认错误，才会轻松地专注于研究为什么会出错，以及如何避免这种错误再次发生。如果你连错误都不能承认，何谈学习？

13. 不与团队分享你学到的东西

你作为一个开发者的价值不仅存在于你写的代码中，还存在于你在写代码的时候学到了什么。分享你的经验，写下相关的评论，让其他人知道为什么事情是这样的，并帮助他们了解项目中难以理解的新事务。

14. 不及时向经理/客户的反馈

工匠精神最有价值的一点是尽可能让所有人在同一层面工作。这样做并不是因为管理者需要填写电子表格。这也是为了你自己：这会减轻你的不安全感，减少对项目生命周期和未来的不确定性。

15. 少用 Google

解决一个问题最快的办法并不是去解决它。如果有问题，上 Google。当然，当然你也可以麻烦坐你旁边的工程师，但他可能很少会给出像 Stack Overflow 上那样详细的解释，更不用说你这样做会打断他的工作。

16. 高估你的个人风格

始终协调自己的工作风格和工作环境与团队保持一致。理想情况下，团队中的每个人都应该工作在类似的环境，遵从相同的代码风格。用你自己的方式来做事情可能会更有意思，但同事可能会不习惯你的代码风格。如果你的风格不同寻常，那别的开发者就很难接手你的工作。

17. 为代码绑上个人的标签

如果某人评论你的代码，不要认为这是私事。你的代码应该经得住考验；也就是说，你应该能解决为什么这样写。如果代码需要改进，那是因为代码需要改进，而不是因为你。

编写代码

18. 不知道如何优化

良好而正确的优化策略需要经验的积累。这产生了探索、分析和了解每个系统的过程中。让自己知道这些事情，学习算法的复杂度、数据库查询评估、协议以及一般情况下如何衡量性能。

19. 使用错误的工具来工作

你所知有限，但让你保持学习的原因是新问题会引出不同的上下文，需要不同的工具——适用于当前任务的工作。以开放的心态面对新的库和语言。不要总是根据自已经知道的事情来做决定。

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

在使用工具的过程中不断学习新的热键、快捷方式或参数，可以提高你编码的速度和认知。这与使用热键来节约几秒种时间无关，它会降低你上下文切换的频率。你花在每个小动作上的时间越多，花在考虑问题(为什么这么做，接下来该干什么)上的时间就越少。掌握捷径会让你恍然大悟。

21. 忽略错误消息

在没有阅读错误消息之前，不要假设你知道代码有什么问题，也不要假设你会很快发现问题所在。掌握更多关于问题的信息总不是坏事，长远来看，花时间收集这些信息会更节约时间。

22. 夸大你的开发工具包

有时候你首选的编辑器或命令行工具并非解决手头工作最好的工具。Visual Studio 是个非常不错的 IDE，Sublime 则非常适用于动态语言，Eclipse 与 Java 更配，等等。你可能比较喜欢 Vim 或者 Emacs，但并不表示它们适用于每项工作。

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

思考变化以及如何处理变化是件长期的事情。如果你不把随时变动的碎片从工作中剥离出来，技术债务就会以惊人的速度增长。应该在适当的地方使用常量和配置文件。

24. 总是重新发明轮子

不要写你不需要的代码。也许别人已经花了大量的时间在你遇到的问题上，他或者她可能已经有一个通过测试的解决方案，你可以重用这些方案，少给自己找麻烦。

25. 盲目复制/代码

你在重用一段代码前应该搞懂它。有时候你不能在第一次看代码马上就注意到它干的所有事情。你应该花点时间仔细阅读代码同时深入研究要解决的问题。

26. 不花时间去研究事务是如何工作的

通过思考事务如何工作，以及它们潜在的问题，抓住机会扩大自己的知识面。你现在可能节约了时间，免受干扰，但长远来看，从项目中学到的东西会比现在做的更重要。

27. 对自己的代码过于自信

只因为是你自己写的东西，就是一级棒，这种假设非常危险。学习更多关于编程的知识，就像新的工作任务那样，从中获取经验。所以，看看你以前写的代码，反思，并获得进步。

28. 不权衡每个设计，解决方案，或库

每个产品都存在优点，你只能通过使用和分析来进行了解。看一个库和几个用法示例不会让你掌握它，也不是说任何情况下它都可以完善适用于你的项目。辩证的看待你所使用的每个事物。

29. 卡住时不寻求帮助

保持简短的反馈循环并如你所想的那么痛苦。寻找帮助并不代表你无能。人们会看到你的独立，承认无知可以驱动学习，这是美德。

测试和维护

30. 写可以通过的测试

写你明知可以通过的测试是有必要的。它们会在项目重构或重新组织的时候保证其质量。但另一方面，你也必须写明知不能通过的测试。它们可以推进项目并跟踪问题。

31. 不顾关键用例的性能测试

在项目开发的中间节点建设一个自动化的性能设置，这样在项目逐步扩大的时候才能确保没有性能问题。

32. 不检查构建工作

构建通过但构建结果却不能工作这种情况很少发生，但它确实会发生。而且，你拖延着不去调查这个问题的话，时间越长，就越难以修复。构建之后进行快速测试是个很重要的习惯。

33. 最后推送大量改动或推送大量改动之后就离开

可能这是因为你过度自信，直到多次引火上身之后才学会不这样做。请现在就接受我的建议，当构建失败的时候你就在旁边。

34. 与自己的代码断开联系

对自己写的代码提供支持。你是最了解这个代码而且最可能为别人提供相关帮助的人。你应该努力使自己的代码在多年后仍然能被自己或者别人看懂。

35. 忽略非功能性需求

发布的时候通常很容易忘记一些重要的领域，比如性能和安全性。应该有这一个清单记录着这些事情。你肯定不希望因为在制定最后期限的时候忘了这些非功能性需求而破坏你的聚会。