当您以非法的方式滥用设计模式，或者您不知道它的实际用法时，有时会使用它。例如，为简单类使用构建器模式，或者为代码中使用的每个Active类定义一个单例实例。

它也可能超出了设计模式。例如，在Java中将局部变量定义为final，或者当您可以简单地检查输入是否为空时使用try / catch作为NullPointerException，或者在使用对象(就像您在其他一些语言中所做的那样)后将其置空，而您没有注意到垃圾收集机制，或者调用system.gc()以使内存为空，以及许多其他误解，这些很可能被认为是Cargo-Cult现象。

因为模式是被发现的，而不是被创造出来的，Allen Holub，这种发现是通过重复发生的;如果我们发现了一个解决特定问题的模式，但不是根据领域专家的知识和经验以正确的方式解决的——我们倾向于称其为反模式

模式:解决常见的、反复出现的问题的正确方法。 反it模式:不是解决常见的、反复出现的问题的正确方法。 这两种方法都是基于最新的知识

和…昨天的有害实践就是明天的反模式Neal Ford，持续交付的工程实践

DevOps世界示例

它曾经是一个最佳实践(构建共享资源)

但在云世界中，当我们在云中管理资源时，它引入了耦合。

所以现在我们倾向于基于解耦或解耦来构建我们的设计

因此，对于特定的领域，例如DevOps:

过去: 共享资源== pattern ==好事 礼物: 共享资源==反模式==坏事 解耦==模式==好事

总之

更喜欢模式而不是反模式

图片来源:Neal Ford，持续交付工程实践

有趣的是，解决问题的特定方法可以是模式也可以是反模式。单例就是最好的例子。它将出现在两套文学作品中。

反模式是人们倾向于以错误的方式编程的常见方式，或者至少是不太好的方式。

在基于微服务的领域:

一切都是微的，除了数据是反模式。 它是指基于DevOps和CI/CD对每一件事情进行合理、充分的分解。也许有些分布式设计模式已经到位，甚至完全复制，但所有服务背后都有一个巨大的数据存储，因此它仍然是一个单一的数据结构。

微服务反模式的其他例子

今天，软件工程研究人员和实践者经常互换使用术语“反模式”和“气味”。然而，它们在概念上并不相同。维基百科上关于反模式的条目指出，反模式与坏实践或坏想法至少有两个不同之处。反模式是

一种常用的过程、结构或行为模式 最初看起来是对一种疾病的适当而有效的反应 问题，通常有更多的坏后果比有益的结果。”

它清楚地表明，选择反模式是因为相信它是当前问题的一个很好的解决方案(作为模式);然而，它带来的负债多于收益。另一方面，气味只是一种糟糕的实践，它会对软件系统的质量产生负面影响。例如，Singleton是一种反模式，God类(或不足模块化)是一种设计气味。