可能会破坏您的软件开发项目可扩展性的十大不良编码实践。根据“帕累托法则”，一个特定事件的最终结果，80%往往是由20%的随机性决定的。这种划分方式被称为28/80原则，它几乎影响到人类生产生活的各个领域。在软件开发的世界里，这个原则也可以解释为：大多数问题实际上是由少数不良编码习惯引起的。通过去掉等式中的这一部分，我们的工作变得更轻松、更有效率。在今天的文章中，我们就来看看给软件开发工作带来无限麻烦的十大编码不良做法。1.代码中出现错别字的频率可能远比你想象的要多。此类问题之所以如此普遍且难以控制，主要是因为问题的根源与我们的编程水平没有必然的关系。再优秀的开发者，也有可能不小心在代码中写错变量名或函数名，而这最终会成为一股肆虐的、最具破坏力的力量。更重要的是，查明它们并不是一件容易的事。那么我们如何解决这个问题呢？选择一个好的集成开发环境（简称IDE）或者专为程序员设计的文本编辑器，可以显着降低出现错别字的可能性。另外，我们可以选择另一种解决方案：刻意选择不难拼写的变量名和函数名，这样即使有错误，也不会太难找。***不要用receive这样的词，因为无论我们检查多少次，都不太可能发现它被拼错为recieve。2.代码内容缺少必要的缩进或格式调整。请记得为代码行设置缩进或格式调整，否则你最终会发现你的代码内容很难阅读，也很难发现错误。此外，简洁明了的格式规划也能提供更统一的展示效果，从而降低后继者维护代码的难度。如果你使用的IDE没有提供自动调整代码格式的功能，我们可以考虑使用Uncrustify等代码美化工具，它可以根据用户事先设置的配置策略自动完成格式转换。3.未能实现代码模块化在编写功能时，重要的是要确保它能够并且只能实现单一的效果——这也是一个值得认真遵循的良好编码习惯。这种方法使代码保持整洁，从而更易于理解和维护。长函数可能有多个可能的访问路径，使它们更难测试。这里教大家一个好方法：一个功能最多不能超过单屏显示内容的限制。另外，如果代码中包含十个或更多的“if”语句或循环，则说明逻辑关系过于复杂，应立即回调重写。4.保持警惕：IDE功能的安全性可能不是真正的IDE和其他自动调整代码的工具可以神奇地提高生产率。这些工具会根据您已经输入的内容建议变量和其他提示。然而，这些工具在实际使用中存在潜在的问题——人们往往会放松警惕，因为他们可以毫不费力地从看似正确的选项中选择他们需要的东西。不要这样做，请仔细检查以确保我们选择的内容与您需要的内容完全一致。从本质上讲，这种功能相当于把思维工作转移到了工具上，所以保证其思维正确当然很重要。这相当于为我们提供了一个新的思维标杆。代码完成工具可以消除拼写错误并提高工作效率，但它们也有可能在我们放松警惕时掩埋错误。5、硬编码密码以硬编码的方式创建秘密账户和密码是非常有吸引力的，这样大家在后续的使用过程中就可以直接进入系统。相信大家都知道这种做法是不正确和不科学的——是的，这种方法确实很方便，但同时也相当于给任何有意窥探源代码的人提供了可乘之机。真正的问题是硬编码密码总是最终会分发给我们没有预料到的人。这使它成为一个巨大的安全威胁，而且很难完全修复。6、没有使用良好的数据保护加密机制敏感数据在网络传输过程中必须进行加密，因为在传输过程中很可能被恶意方截获。这不仅仅是一种冲动或建议，而是一种管理要求——甚至可以上升到执法层面。也就是说，明文直接发送数据的做法必须“严禁”。此外，您不得使用自己编写的加密或混淆方案。编写自己的安全加密系统非常困难——我相信你会明白WEP是怎么回事——所以一定要选择符合相关行业标准的加密库并正确使用。7.过早地优化代码传奇的编程大师DonaldKnuth曾说过，“程序员花很多时间思考或担心程序非关键部分的执行速度，但这样的处理措施往往会给代码带来严重的负面影响影响我们的调试和维护工作。”多关注我们的代码确实可能让它的执行速度不断提升，但是也会给调试和维护带来更多的难度，最好的办法是：把代码写得简洁明了，然后通过优化来提升它的性能8.缺乏超前思考能力我们的项目要做什么，扩展到什么程度，有多少用户操作，以什么速度运行？这些问题的答案在开发过程中往往是不明确的开发过程——但如果不能提前规划，就无法选择合适的框架，开发出能够满足这些需求的应用。Twitter的技术团队就遇到过这样的实际情况：如果未来实际使用强度被低估，后期补救难度极大，Twitter不得不彻底放弃RubyonRails，改用Scale等技术方案重写代码，这是因为原来的Ruby代码并不是最初设计的d与Twitter的快速用户群增长率无关。9、增加开发人员数量，提高开发进度很少有软件项目能真正按预定时间完成进度。增加开发人员数量以提高开发进度乍一听似乎是个好主意，但这是理论多于现实，有时甚至是严重的错误。实际上，向项目中添加新人总是会降低团队的整体生产力。10、明知时间计划达不到却还在苦苦挣扎的同时，也要保持清醒的头脑，认识到在团队规模相同的前提下，进度落后的局面是无法逆转的——这样的理性思考能力很重要。如果大家没有完成原来的时间表，很可能是这个时间表的制定有误。换言之，我们需要出台新的项目时间表，而不是盲目固守原先已被现实证明不可能的错误计划。英文：http://www.javaworld.com/article/2393057/developer/10-bad-coding-practices-that-wreck-software-development-projects.html
