任何听过青少年、体育评论员或企业管理的人都知道，词汇和含义之间的联系可能是不固定的。一种新的舞蹈热潮可以同时“酷”和“热”。明星球员的“病态动作”并不需要任何医疗护理。而且，如果一家公司要进行“重组”，这对任何人都没有好处，可能除了股东——即使那样，情况也并不总是明朗。
计算机世界总是为这种疯狂提供了喘息的机会。没有人会把“一”放在“零”的位置上。没有一个类型如果x = 0当他们真正想说的时候如果x != 0．逻辑是在一个充满混乱和欺骗的世界里提供稳定的基石。
唉，当你超越1和0时，即使是计算机科学也不是那么清晰了。有些想法、方案或架构可能真的很糟糕，但它们也可能是您的项目的最佳选择。它们可能更便宜或更快，也可能用正确的方式做事太难了。换句话说，有时候坏就足够好了。
有时坏主意也会带来一线希望。这可能不是最好的方法，但它有很好的副作用，这是一种方法。如果我们陷入了编程地狱的次优路径中，我们不妨充分利用埋藏在那里的宝贵资源。
这里有7种真正糟糕的编程实践，但它们往往都很有道理。
快速而粗糙的代码
几乎没有什么比糟糕的设计和文档化的代码更能杀死一个项目了。即使你的堆叠站起来了，保持它将是一场噩梦。任何继承了你那堆热气腾腾的肉的人，都将成为你一生的死敌。
再说一次，快速和肮脏的代码也有它的位置。事实上，追求干净、彻底的工程代码可能代价高昂。我曾与一位编程经理共事，他看着每个人的眼睛，列举了一长串需要清理软件的方法。我们的旧代码可能已经运行了，但公司会再拨出两个月的预算，以确保代码行是像样的。有时我们的编程经理会要求六个月的预算，她会得到它。毕竟，谁想要不干净的代码呢?
并不是每个人都能获得这样的预算，而且很少有人愿意告诉预算经理再拿出N个月的开发时间，因为干净的代码是最好的。
更糟糕的是，清洁通常是一个模糊的概念。一个程序员干净的代码是另一个程序员过于复杂的代码。清理代码通常意味着添加新的抽象和层，以明确代码正在做什么。这很快就会变成TMI。有时，快速而肮脏的代码比复杂的“干净”代码要好，后者与“战争与和平”的文档相匹配。
任何阅读过一页又一页设计良好的代码的人都知道，有时只需输入一点简单的代码，加上一个简单的工作描述，就能胜过一大堆精通工程和计算机科学的东西。简单但实用的代码需要10秒钟才能理解，而复杂的架构则需要数周的时间。
这并不是说做好工作就是坏事——然而，很多时候，没有人有时间或精力去展开所有复杂的工作。当时间不足时，有时快速草率的做法会取得胜利，而且会取得巨大的胜利。
浪费的算法
有时候聪明并不值得付出代价。当涉及到深入研究的具有强大理论基础的算法时，这一点再明显不过了。
每个人都知道大学的教训。智能数据结构将在与数据大小成比例的时间内完成这项工作。一个糟糕的可能会在时间上变慢，与数据元素数量的平方甚至立方成比例。随着数据量的增长，一些真正可怕的数据会呈指数级增长。计算机科学课的课程很重要。糟糕的算法可能非常慢。
问题是，聪明的、理论上有效的算法也可能很慢。它们通常需要复杂的数据结构，充满指针和中间值的缓存，这些缓存会占用RAM。它们可能需要几个月或几年的时间才能恢复正常。当然，从长远来看，他们会更快，但经济学家约翰·梅纳德·凯恩斯说过什么?“从长远来看，我们都死了。”
部分问题在于，大多数理论模型分析了当数据集变得非常大时算法的行为。但即使在大数据时代，我们可能也无法处理足够大的数据集，以享受所有的理论节省。
在这些情况下，一个草率的算法可能是一个好主意，即使它可能很慢。
使用单独的数据库服务器
当涉及到软件性能时，速度很重要。在网络上的几毫秒可能是提前退休和彻底失败的区别。一般的做法是:为了加快软件各层之间的通信速度，将数据库与软件放在同一台机器上，以便为用户打包结果。有了数据库代码和表示层的快速通信，就消除了必须ping另一台机器的延迟。
但是它并不总是有回报，特别是当一台机器不能有效地同时满足表示层和数据库层的需求时。
运行数据库的机器通常与运行演示软件的机器有很大的不同。更复杂的是，这些差异取决于所使用的数据库的类型和结构。更多的RAM总是有帮助的，但当涉及到索引时，这是必要的。大的表比大量的小表需要更多的RAM。如果您计划进行许多join，那么最好不要使用一体化的趋势，而是使用独立的数据库服务器。
当你把数据库和软件的其他部分放在一起时，这台机器就不得不成为多面手。它可能能够快速地与自己通信，但它无法有效地执行代码的每个不同任务。
用一个大的CMS锤子在一个小钉子上
当今的趋势之一是将中心中心的工作剥离，并将其拆分为轻量级的微服务。您不需要为所有数据构建一个门户，而是构建几十个甚至上百个独立的web服务，专门用于回答特定的查询和收集特定的数据。这样做可以让您独立地创建、调试和部署每个服务——非常适合进行迭代更改，而无需升级单个代码库。
但是使用WordPress或Drupal这样的大型内容管理系统来做同样的事情，是另一种提供JSON或XML数据的方式，只需稍加重新配置。乍一看，这似乎是一个糟糕的想法，因为CMS的额外复杂性只会降低堆栈的速度。但是CMS方法也可以加速开发并改进调试。所有的数据格式化和“内容管理”都可以为管理系统的内部人员服务。即使没有用户接触到这些华丽的层，它仍然可以为内部用户提供很大的帮助。
额外的开销可能是一个痛苦的问题，但通过向后端添加更多的计算能力，它相对容易解决。
数据显示集成
现代设计的基本规则之一是将项目至少分成三个部分:数据存储、决策制定和表示。这样的分离使得独立于其他两个部件的任何一个部件的重新设计更加简单。
但是也有缺点，因为将显示与数据分离意味着应用程序不断地重新处理数据以适应当前的显示模板。如果模板保持不变，其中大部分将重复。
最近，架构师一直在修改数据格式，使显示代码更容易处理。之所以转向JSON数据结构和JSON NoSQL数据库，很大程度上是因为希望以一种更便于浏览器处理的格式交付数据。它并不是把数据和显示代码混在一起，而是把它们拉近了。
使用缓存通常是应用程序混合显示代码和数据的方式。当数据混合到模板中时，结果会被存储回数据库中，以便一次又一次地服务。
使用一个次优的基础
过去，为您的长期增长目标选择“错误的”架构或策略意味着即将到来的项目死亡。然而，如今，从糟糕的早期选择中恢复过来相对容易，只要在问题上投入更多的云机器仍然是可行的解决方案。
如果您的服务器堆栈变慢或数据库陷入困境，您通常可以打开拨号并租用更多的机器。然后，当人群散去时，您可以调整额外的计算能力。当额外的机器每小时只花几分钱，它不再是灾难性的架构错误。
当然，不是所有的错误都可以通过扔硬币来解决。当公司发展时，一些糟糕的决定导致了指数级的崩溃。当云计运行时，这类故障会迅速掏空所有钱包。但是，只要不复杂化，简单地选择一个乏味的数据库或一个慢两倍的精心设计的过滤器并不是什么问题。
关键是要避免设计中最关键部分的瓶颈。保持移动部件的分离和独立有助于确保它们不会相互干扰并产生致命的锁定。只要核心架构不产生僵局，糟糕的决策就可以用更快的硬件来掩盖。这并不漂亮，但通常很有效。
以Facebook为例，这家公司开始使用PHP, PHP是早期的网络应用工具之一，但在Facebook推出时，它已经有点过时了。然而，令人不快的问题是那些困扰程序员而不是用户的问题。尽管语法很奇怪，功能也很有限，但这种方法还是很可靠的。Facebook通过创建HHVM刺激了PHP的开发，HHVM是一个更快的版本，激发了对PHP核心的重写。现在，Facebook运行旧代码的速度快得多，用户也不知道，该公司选择了一个早期的平台，这仍然让一些程序员感到眼红。
选择一个还过得去的解决方案通常比设计一个复杂的新方法要便宜。让所有人坐下来重新设计软件以使其平稳有效地运行可能会花费一大笔钱。一个聪明的程序员一年能挣20万美元——但这可能比亚马逊数百万个服务器小时还要多。当更多的硬件廉价且可按小时出租时，聪明往往不值得麻烦。
在生产中保留满是灰尘的代码
有一次，一个经理团队叫我去看一个时髦的、现代的web应用程序，它是用最新的想法和最新的语言开发的(当时是Java)。问题是，旧的主机与单色哑终端的通信速度快得多，以至于每个必须使用新代码的人都在抱怨。我们不能回到60年代的科技时代吗?
一个新的Java程序员甚至沮丧地告诉我，“将我们与旧的绿屏应用程序相比是不公平的，我们做了太多。”他所说的“更多”指的是使用花哨的字体、雅致的颜色和适合可调整大小的窗口的形式。同样的数据仍在从手指移动到数据库，但接听电话的人记得，使用花哨的绿色屏幕和固定宽度的字体工作要快得多。
最新的软件技术并不总是一种进步。有一个原因让硬件工程师窃笑，程序员的存在是为了创建无数行的新代码，以确保新硬件运行得和旧的一样慢。否则就不需要新硬件了。
一些认真的程序员喜欢用严肃的口吻谈论“技术债务”和“持续重构”等问题。他们很有学问地谈到了投资更新代码的重要性。但有时，想要一笔勾销、重新书写一切的梦想会变成一场噩梦。
这是一个艰难的决定。如果旧代码有bug或失败，重写是唯一的选择。但有时仅仅为了保持应用的更新而重新构建应用可能是一个很大的错误。有时您会倒退，最终得到一个用最新语言编写的时髦架构，但其中充满了新的、时髦的bug。
相关文章
- 7种我们又爱又恨的编程语言
- 9个我们偷偷喜欢的坏编程习惯
- 21个热门编程趋势和21个冷门编程趋势
- 下载:专业程序员的商业生存指南
- 下载:成功成为独立开发者的29个秘诀
- 关于编程“老人”的5个永恒教训
- 没有开发者愿意听到22种侮辱
- 对未来编程的9个预测
- 你现在需要掌握的13项开发技能
- 规划世界:12项你现在需要知道的技术
- 单字母编程语言的攻击
这篇文章，“7个可行的糟糕编程想法”最初发表于信息世界 ．