35 个毁掉你代码的不良习惯 ！

引言

坏习惯很难改变，若是你不知道你的坏习惯正在影响工做，那就更难。若是你知道，但不在意——这是最糟糕的状况。但好在你已经来这里看了，不是吗？

做为一个程序员，我看到不少很差的作法，不只仅与代码相关，还包括团队合做能力。我本身曾经就有很多这些坏习惯。这里是我认为最糟糕的 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. 忽略非功能性需求 发布的时候一般很容易忘记一些重要的领域，好比性能和安全性。应该有这一个清单记录着这些事情。你确定不但愿由于在制定最后期限的时候忘了这些非功能性需求而破坏你的聚会。