原文来自Wikipedia, 自由百科全书.本文根据需要，节选自译言 Korner 翻译的文章《反面模式》。 原文链接 。
在 软件 工程中，一个反面模式（anti-pattern或antipattern） 指的是在实践中明显出现但又低效或是有待优化的 设计模式 。
Andrew Koenig在1995年造了anti-pattern这个词，灵感来自于GoF的《 设计模式 》一书。而这本书则在 软件 领域发明了“ 设计模式 ”（design pattern）一词。三年后antipattern因《AntiPatterns》这本书而获得普及，而它的使用也从 软件 设计领域扩展到了日常的社会互动中。按《AntiPatterns》作者的说法，可以用至少两个关键因素来把反面模式和不良习惯,错误的实践或糟糕的想法区分开来：
很多反面模式只相当于是错误、咆哮、不可解的问题、或是可能可以避免的糟糕的实践，它们的名字通常都是一些用反话构成的词语。有些时候陷阱（pitfalls）或黑色模式（dark patterns）这些不正式的说法会被用来指代各类反复出现的糟糕的解决方法。因此,一些有争议的候选的反面模式不会被正式承认。
【1. 已知的反面模式】
【1.1 组织结构的反面模式】
从天而降的责任（accidental ownership）：雇员们接手了一个与当前系统完全无关的系统，在没有合适的训练、学习或关心下就得维护它（在90年代的电话->网络管理员中很常见）
分析麻痹（Analysis paralysis）：在项目的分析阶段付出的努力太少
引擎室里的船长（Captain in the engine room）：团队带头人把时间和精力全花在技术问题上，没有人开船
摇钱树（cash cow）：盈利的老产品通常会导致对新产品的自满
持续退化（Continuous obsolescence）：不成比例地投入精力把系统移植到新环境下
经费转移（Cost migration）：项目经费转移到弱势的部门或商业伙伴那里
危机模式（Crisis mode）或救火模式（firefighting mode）：硬是等到火烧屁屁的时候
委员会设计（Design by committee）：很多人同时进行设计，却没有统一的看法
委员会扩张（Escalation of commitment）：明知错了还不能收回之前的决定
英雄模式（Hero-mode）：长期依赖成员的英雄式的努力来满足不可能的任务期限，同时又忽视从一开始就没有注重 软件 品质带来的损失
我早就说过（I told you so）：某人之前的警告没得到重视，事后又被人发现是正确的，并引起了关注
主观管理（Management by hope）：认为平静的表象就代表一切顺利
通过忽视的管理（Management by neglect）：过多地委任
用数字管理（Management by numbers）：过于关注非本质而又不易取得的数字指标
Perkele管理（Management by perkele）：用完全听不进异议的独裁作风进行管理
思考管理（Management by wondering）：希望一个团队定义自己的目标，然后考虑他们要做什么
精神危险（Moral hazard）：不让做决定的人知道他的决定会带来什么结果
蘑菇管理（Mushroom management）：有事也不通知雇员或是错误地通知（像种蘑菇一样放在黑地里施肥）
不是这里发明的（Not invented here）：拒绝使用组织外的主意或方案
精益求精（Polishing the polish）：把已经完成的项目交给下属去做，禁止他们做其它的事，又报怨他们低效率
规模爬行（另外两个类似的词是复杂度陷阱和功能主义者）：不适当控制项目的规模的增加
烟囱（Stovepipe）：结构上支持数据主要在上下方面的流动，却禁止平行的通信
客户套牢（Vendor lock-in）：使一个系统过于依赖外部提供的部件
小提琴弦组织（Violin string organization）：高度调整和裁减却没有灵活性的组织
【1.2 项目管理的反面模式】
死亡征途（Death march）：除了CEO，每个人都知道这个项目会完蛋。但是真相却被隐瞒下来，直到大限来临
拖后腿的无知（Heel dragging blindness）：项目经理的无知拖了后腿。出于某些动机，员工趋向于减少努力来延长项目时限。例如，他们是按时间（而非结果）付费，又没有能顺利转移过去的后续项目
烟和镜（Smoke and mirros）：展示还没完成的函数会是怎样
软件 膨胀（Software bloat）：允许系统的后续版本使用更多的资源
【1.3 团队管理的反面模式】
缺席的经理（Absentee manager）：经理长时间不出现的情况
Cage match negotiator：经理用“不惜一切代价也要取胜”的方式来管理
Doppelganger：某些经理或同事刚才还平易近人，过了一下就变得难于相处
无底洞（Fruitless hoops）：经理在做出决定前要求大量的（通常是无意义的）数据
黄金小孩（Golden child）：依据人情而不是实际的表现，特殊的责任、机会、认可、奖励被给予团队成员
无头苍蝇（Headless chicken）：经理总是处于恐慌中
领导而非经理（Leader not manager）：经理是一个好的领导，却缺乏行政和管理能力
管理克隆（Managerial cloning）：经理对所有人的雇佣和指导的方法都是一样的：像他们的老板
经理而非领导（Manager not leader）：经理能胜任行政和管理职责，却缺乏领导能力
指标滥用（Metric abuse）：恶意或是不适当地使用指标
好好先生（Mr. nice guy）：经理想成为每个人的朋友
鸵鸟（Ostrich）：有些人员整天做些空洞的事情却忽视那些需要在最后期限前被解决的事情还以为会没事，通常更希望看起来很忙，但实际上会浪费和用尽时间
平民英雄（Proletariat hero）：口头上称赞普通员工技术如何如何之牛，实际上管理层只是把他们当成棋子，目的是有借口更多的摊派任务以及增加生产目标
得势的暴发户（Rising upstart）：指这样一些潜在的新星，他们急不可耐地想要爬上去，不愿花费量些必要的时间去学习和成长
海鸥管理（Seagull management）：飞进来，弄得鸡飞狗跳、一片儿狼藉，然后就拍拍屁股走人
懦弱的执行者（Spineless executive）：管理者没有勇气来面对当前形势、来承担责任、或是来保护自己的下属
三个脑袋的骑士（Three-headed knight）：没有决断力的管理者
终极武器（Ultimate weapon）：有些人完全依赖自己的同事或是组织，好像他们自己只是一个导体，把问题全部传给别人
热身状态（Warm bodies）：指有些员工几乎不能达到工作的最低要求，因此不断地从一个项目转到另一个项目，或是从一个团队换到另一个团队。
只会说是的人（Yes man）：指一些管理者当面对CEO说的每句话都说是，CEO不在的情况下他可能说的又是另一回事
【1.4 分析方式的反面模式】
尿布说明（Napkin specification）：把给开发团队的功能或技术说明写在尿布上（即是说，不正式，又缺乏细节），和根本就没有说明一样
假需求（Phony requirements）：所有的需求都是通过网络会议或是电话通知给开发团队的，没有任何功能、技术上的说明或其它说明文档
火箭说明（Retro-specification）：在项目已经启动之后才开始写技术、功能说明
[1.7 方法学上的反面模式]
拷贝粘贴编程（Copy and paste programming）：拷贝（然后修改）现有的代码而不是假
拆除（De-factoring）：去掉功能，把它转化成文档的过程
黄金大锤（Golden hammer）：认为自己最喜欢的解决方案是到处通用的（见：银弹）
未必有之事（Improbability factor）：认为已知的错误不会出现
低处的果子（Low hanging fruit）：先处理更容易的问题而忽略更大更复杂的问题。这个问题有些类似于这种情况：科学、哲学和技术上的发现在早期都比较容易得到，一旦问题已经被人研究过了，再要有所创新就难了
不是这里做的（Not built here）：见“重新发明轮子”、“不是这里发明的”
不成熟的优化（Premature optimization）：在编码的早期追求代码的效率，牺牲了好的设计、可维护性、有时甚至是现实世界的效率
转换编程法（Programming by permutation）：试图通过连续修改代码再看是否工作的方
重新发明方的轮子（Reinventing the square wheel）：已经有一个很好的方案了，又再
重新发明轮子（Reinventing the wheel）：无法采纳现有的成熟的方案
银弹（Silver bullet）：认为自己最喜欢的技术方案能解决一个更大的问题
测试人员驱动开发（Tester driven development）： 软件 工程的需求来自bug报告
