避开这 35 个坏习惯让你的代码可维护
本文翻译自 Avoid these 35 habits that lead to unmaintainable code
坏习惯难以改变，它会以意想不到的方式影响你的工作。如果你只是知道这些习惯，但并不在乎它，事情将会变得更糟。你既然来读这篇文章了，我想你肯定是在意这些坏习惯的。
作为一个程序员，我见过很多不好的开发方式。这不仅体现在代码方面，还体现在团队协作方面。这 35 个习惯都是我本人的一些坏习惯，我并不以此为荣。我将按照代码组织、团队协作、编码、测试、维护这些类别来描述这些坏习惯。
代码组织
1. “我承诺修复这个问题”，实际却永远也不去做。
延后修复这个坏习惯不仅仅只是一个定义问题的优先级。追踪一个问题需要耗费一些进度，但你仍然需要组织好问题追踪过程中的小问题。并在代码里面加上 TODO 确保这些问题不会被遗忘掉。
2. 过度追求代码的简洁性
追求代码的 “优雅”，“简洁” 是程序员的常见特质。当你把一个 20 行的正则表达式简化成 2～3 行，这就像解谜一样有趣。不幸的是，这并没有让代码变得更有利于阅读。代码可读性好才是更重要的，你应该首先确保这一点，然后再考虑代码的 ”优雅“。
3. 毫无目的的优化
我们常常会做一些没有意义的优化。这就好比通过优化文件大小来提高网站的加载速度。但为何不直接用 gzip 压缩？优化 request 难道不更有效吗？把优化工作放到项目结束的时候做，因为一般情况下优化是没有必要的，没有必要的优化就是在浪费你的时间。
过早的优化是万恶之源。
－Donald Knuth
4. 不注重代码风格
如果我多年来一直在学习他人的代码， 最不需要了解的就是这个开发者的代码风格。或许没有经验的开发者很难看出代码风格带来的问题。但大多数时候风格问题将会使项目脱离正轨，从而带来雪崩一样的混乱。在细微处保持严格最佳实践，启用 lint 检查工具，这些将会让你从这些细节中结果出来， 从而去关心更重要的问题。
5. 掩埋错误
无论捕获还是忽略异常或者使用不报告错误的库，掩埋错误的方式有很多种。但如果这些错误其中一个优先级变得很高，修复比忽略它要难很多倍，尤其是在你无从下手的时候。简单一点的方式就是避开它，然后纪录下来以便以后追踪。
6. 命名没有包含足够的信息
命名很难，但有简单的方法可以让你的函数和变量命名合格。只要你在名字里面包含特定的信息，不要传递额外的信息，你的代码可以容易的让别人阅读。命名如此重要的原因在于它可以描述代码具体的作用。好的命名会让你更容易理解代码的作用，否则你需要花费更多的时间才能深入的了解代码的作用。
7. 忽略更好的实践方式
代码复查(Code review)，TDD，QA，自动部署这些业界优良实践，为不计其数的项目产生了价值。这也是为什么开发者的 blog 会经常提到这些东西。这方面有一本非常好的参考书 Making Software: What Really Works, and Why We Believe It. 花点时间去学习如何正确的运用它们，将会对你的项目开发进度获得令你惊讶的提升。
团队协作
8. 过早的丢弃计划
一个确保你的系统变得难以捉摸的方式就是不制定计划。甚至可以说计划没有完成，代码再好也没用。但如果你想把一个半成品模块尽快投入使用的时候，你这个模块的代码将变成耦合度很高的一坨代码。这种情况也发生在一个新的经理决定把项目替换成他自己熟悉的那一套架构的时候。
9. 坚持一个不能有偏差的计划
不按计划行事会碰到问题，完全按计划行事是很难办到的。这就是为什么你需要不断的把你的想法告诉团队成员，让他们在困难的事情上给予反馈和建议。一般情况下不同的观点会让事情变得不一样。
10. 长期单独行动
你应该不断的分享你的进度和想法。有时候你觉得你在做正确的事情，但实际上不是，这时候频繁的沟通是非常有益的。频繁的沟通还能帮助和你一起工作的人。你和人们讨论想法，帮助团队里陷入困境的新手，他们都能从中进步。
11. 拒绝写坏的代码
在每一个开发者的职业生涯中都会碰到因为“赶工”而被迫去写烂代码，这种情况并不糟糕。在你已经尝试过警告客户或者更高一级领导关于进度的问题时候，他们仍然坚持要在限定时间内完成。这时候别管太多，去堆代码好了，那些紧迫的 bug 给不了你太多时间去找最佳的解决方案。这就是为什么对于程序员来说能快速写出能解决问题代码的能力很重要的。不过最好是你要能回去把那些烂代码改掉，别积下太多的“技术债”。
12. 指责他人
相对于其他专业技术人员，软件开发人员更加自大。勇于承担责任的美德会让你在同事间脱引而出。不要羞于承认你犯过的错误。一旦你处理好了这种羞愧，你将会更好的去探知为什么会犯错以及如何避免犯错。反之你很难在你犯过的错误中学习。
13. 不和团队分享你学习成果
作为一个开发者，你的价值不仅体现在你写得代码，而且还体现在你从中学习到的东西。分享你的经验，写一些注释，让其他的人也知其所以然，以便帮助他们学习新的东西和困难的东西。
14. 给客户／领导的反馈太慢
技术人员最明显的一个特质就是容易认为所有人都和他是在一个领域工作的。这不是你的领导只是用来打电话填表格的原因。给他们反馈是为了你自己好，这样做你会减少项目进度不安全感并减少现在和未来的不确定性。
15. Google 用得不够
解决复杂问题最快的方式不是去彻底解决它。遇到问题，Google 一下。你也可以让一个坐在你旁边的工程师帮你。多数情况下他的答案肯定是没有 Stack Overflow 那么详细，反而你还因此打断了他的工作。
16.过度注重你的个人风格
让你的团队的工作风格和环境设置尽量保持一致。团队里的每个人都应该在工作中使用同一种编码风格。按你的风格协作固然很好，但和你合作的人他以前并不是这种风格，并且你的这种个人风格还很罕见，那么对于后加入项目的开发者来说将会很困难。
17.为你的代码留下说明
当有人为你的代码写注释时，不要在意。你的代码将会更加稳健，你应该更进一步向他解释你的代码。你只需要为改进代码去修改错误的部分而已，而不是需要全部推倒从来。
编码
18. 不知道该如何优化
一个非常好的优化策略就是去探索、分析、了解系统的每一个过程。你应该去逐个了解这些东西。去理解算法复杂度，数据库查询开销，通信协议以及如何去测量这些开销。
19. 在工作中使用错误的工具
你懂得的是有限的，这就是为什么你需要去学习不同的问题可以使用不同的工具解决。很少能有一招吃遍天下鲜的。对新的库和语言保持开放。别让决策只基于你懂的那一部分。
20.对你手头的工具和 IDE 用得不够彻底
你每天使用的工具，学习好它的每一个快捷键，快捷方式，运行参数，这会让你的工作效率大大的提升。这不仅仅意味着一个快捷键节省你十几秒的时间，主要是它不会打断你的工作思路。你在这些小动作上花费的时间越多，你会对你手头的工作思考的越少。完全掌控你的工具能解放你的大脑。
21.忽略错误信息
在没有认真读过出错信息前，不要对你的代码做任何已知的假设。对问题收集足够的信息是非常好的。花时间去理解这些信息在长期来看是节约时间的。
22.对你开发工具心存幻想
你可能喜欢使用的命令行或编辑器，但这可能并不是最适合用来做手头上的工作。Visual Studio 是非常优秀的 IDE，Sublime 非常适合动态语言开发，Eclipse 非常适合 JAVA 开发，以及其它工具总是有它最适用的领域。或许你非常喜欢 vim 或 emacas，但它们并不是能胜任各种不同的开发。
23.用灵活的配置取代硬编码
不断的去思考如何去灵活处理开发中的变化。技术债会随着你不去做开发隔离而越积越多，适用约定和配置文件能很好的应对不断变化的情况。
24.总是重新发明轮子
不要去写你不需要写的代码。因为可能已经有人在你当前的问题上花了很多时间了，而且在此基础上他还做了更好测试让你可重用。他们的解决方案会让你避免麻烦。
25. 盲目拷贝代码
理解你直接拿过来用的代码。这些代码有时你是无法在第一眼就能注意到所有的问题。花时间仔细的理解这些拷贝过来的代码将会让你对问题有更好的认识。
26. 不花时间去理解一个东西是如何运作的
你要不断的去找机会实践你的知识，思考它是如何工作的并理解潜在的问题。现在为了节省时间你可能懒得去做这些事情，但长期来看理解你正在做的项目比把它做完更重要。
27. 对你自己的代码过于自信
最危险的事情就是假设你自己写得代码非常好。你学习新事物获得的经验会让你更加理解编程，不定期的回顾你以前写的代码可以看到出你是如何进步的。
28. 不去思考每一个设计、解决方案、库的折衷方案
你通过分析和使用只能了解一个产品好的地方。看少量的示例并不能让你完全掌握它，而且它也不能完全适用于你项目的每一个地方。要持续不断的对你使用的东西保持批判。
29. 陷入困难时不寻求帮助
保持短向的循环反馈会让你少很多麻烦。向外寻求帮助并不意味着你很弱。有智慧的人会看到你承认无知而去学习，这是最好的美德之一。
测试和维护
30. 写测试只是为了让它通过
写你知道它会通过的测试用例是必须的，它们将会使你的项目更加安全。反过来说，你还应该去那些你知道它不会通过的测试用例。在问题跟踪和项目推进时这些都是必须的。
31. 无视关键地带的性能测试
对项目开发过程的中间地带准备好自动化性能测试，它能保证性能不会成为逐级上升的问题。
32. 不去检查代码的 build 结果
很少会发生代码 build 通过，实际上却不能工作的情况。但这样的情况却是存在的。修复这种问题需要等很长时间才能看到结果。所以快速的测试每次 build 是个很好的习惯。
33. 一次 push 大批量的代码或 push 一大堆代码后就不管了
这些都是因为你过于自信，在吃了多次亏后你才会长记性。所以接受我的建议吧，检查你的每一次 build 失败的原因。
34. 摒弃以前的代码
你要乐意维护你自己写的代码，你是最适合帮助别人理解这些代码的人。你应该让你的代码从现在开始到以后很长一段时间保持可读性。
35. 忽略非功能性的需求
当你想推进一些事情的时候，最容易的方式就是暂时忘记一些重要的地方。比如像性能，安全这些事情。你要做一个checklist 记住它们，不要等到上线的时候才想到去做这些非功能性事情。
你有什么程序员的坏习惯
俗话说：“人是习惯性的动物”。通过习惯获得提升的方式就是避免每次碰到问题去思考太多。吸收好的做事习惯会让你很容易进步。