如果我们认为模式代表一个最佳的实践，那么反模式将代表我们已经学到一个教训。受启发于Gof的《设计模式》，Andrew Koeing在1995年的11月的C++报告大会上首次提出反模式。在Koeing的报告中，反模式有着两种观念:
关于这个话题，Alexander写过要在好的设计结构和好的上下文中找到平衡是困难的:
这些笔记是关于设计的过程，这个过程发明显示一个新的物理顺序响应功能，组织形式，物质的东西......每一个设计问题开始于努力实现两个实体之间的形式：问题中的形式和它的上下文。此形式是解决问题的方法，而上下文定义了该问题。
虽然理解设计模式很重要，但对于理解反模式也是同等重要。我们有资格知道这背后的原因。当我们开发一个应用，这个工程的生命周期开始建设一直至项目完成，但一旦完成后，就进入维护阶段。判断一个解决方案的好坏要看这个团队在这个项目上投资的技术和花费的时间。这里被认为是好的和坏的情况下-如果应用在错误的情况下，一个“完美”的设计可能有资格作为一个反模式。
最大的挑战发生于应用进入生产和维护阶段。一个之前没有开发过这个应用的开发者来维护一个系统可能会引进糟糕的设计。如果说糟糕的设计是因为反模式，那么将允许开发者提前找到一种认识到时这样的手段，这样就能避免一些普通错误的发生，与此同时这也是设计模式给我们提供一种认识到普通技术也是有用的方式。
反模式是一个值得为此专门编写编写总结文档的糟糕设计。Javascript的反模式例子如下:
知道反模式对成功来说很关键。一旦我们能识别这些反模式，我们就能够重构我们的代码使项目的整体质量立马提升。