反模式是一种重复的动作，过程或结构，最初看起来是有益的，但最终会产生负面影响。
不仅仅是一个坏习惯。 反模式伪装成解决方案，同时消除了多年来对其造成的广泛破坏。 一旦这些模式浮出水面，通常就会带来灾难性的后果。
组织反模式
- 分析瘫痪：将过多的精力投入到项目的分析阶段
- 按委员会设计：对设计有很多贡献者的结果，但是没有统一的愿景
- 矩阵管理：不专心的组织结构导致忠诚度分散和缺乏方向
- 炉灶或筒仓：一种结构，主要支持上下数据流，但禁止跨组织通信
- 供应商锁定：使系统过度依赖外部提供的组件
项目管理反模式
- 小组思考：在小组思考过程中，小组成员避免在共识思维的舒适范围之外提倡观点。
- 软件膨胀：允许系统的后续版本需要更多的资源
- 瀑布模型：一种较旧的软件开发方法，无法充分应对意外更改
软件设计反模式
- 大泥球：没有可识别结构的系统
- 作为IPC的数据库：使用数据库作为消息队列进行常规的进程间通信，在这种情况下，更轻量级的机制将很适合
- 镀金：继续完成一项任务或项目，远远超出了额外的努力无法增加价值的地步
- 输入错误：无法指定和执行无效输入可能性的处理
- 魔术按钮：直接在接口代码中编码实现逻辑，而无需使用抽象
- 炉管系统：与疾病相关的组件几乎无法维护的组件
编程反模式
- 意外的复杂性：将不必要的复杂性引入解决方案
- 船锚：保留不再使用的系统的一部分
- 忙碌旋转：在等待某些事情发生时（通常在等待任务完成处理时）锁定页面并消耗CPU。
- 错误隐藏：在将错误消息显示给用户之前捕获错误消息，要么不显示任何内容，要么显示无意义的消息
- 硬代码：在实施过程中嵌入有关系统环境的假设
- 熔岩流：保留不想要的（冗余或低质量）代码，因为删除它太昂贵或具有不可预测的后果
- 幻数：算法中包含无法解释的数
- Spaghetti代码：几乎无法理解其结构的程序，尤其是在滥用代码结构时
方法论上的反模式
- 复制和粘贴编程：复制（和修改）现有代码，而不是创建可重用的解决方案
- 不可能因素：假设不可能发生已知错误
- 没有在这里发明（NIH）综合症：重新发明轮子的趋势（未采用现有的适当解决方案）
- 测试人员驱动的开发：在错误报告中指定了新要求的软件项目
