[前言]
design pattern是设计模式，通常是前人在软件开发过程中积累出来的解决一些问题
的现成套路，按它们来做可获益无穷。anti-pattern也是一些现成的套路，但它们是现成的
错误套路，避免它们则亦可获益无穷。本文译者Korner Hill的更多其它翻译和原创文章可
在blog上找到http://blog.csdn.net/KornerHill。
计算机领域内的很多词汇都缺少公认的中文翻译，anti-pattern也是如此，这里译为反面模
式，乃是因为它本身是作为反面教材使用的模式。其实直接用“反面教材”更通俗易懂，但
这里为了保持它与设计模式之间的内在关联，而使用了“反面模式”一词。
来自Wikipedia, 自由百科全书
在软件工程中，一个反面模式（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.5 通常的设计反面模式]
* 抽象倒置（Abstraction inversion）：不把用户需要的功能直接提供出来，导致他们要
用更上层的函数来重复实现
* 用意不明（Ambiguous viewpoint）：给出一个模型（通常是OOAD，面向对象分析与设计
）却没有指出用意何在
* 大泥球（Big ball of mud）：系统的结构不清晰
* 斑点（Blob）：参考上帝对象（God object）
* 气体工厂（Gas factory）：复杂到不必要的设计
* 输入问题（Input kludge）：无法指出和实现对不正确的输入的处理
* 接口膨胀（Interface bloat）：把一个接口做得过于强大以至于极其难以实现
* 魔力按键（Magic pushbutton）：直接在接口的代码里编写实现，而不使用抽象
* 竞争危机（Race hazard）：无法知道事件在不同顺序下发生时产生的结果
* 铁轨方案（Railroaded solution）：由于没有预见和在设计方面欠缺灵活性，提出的方
案即使很烂，也成了唯一选择
* 重复耦合（Re-coupling）：不必要的对象依赖
* 烟囱系统（Stovepipe system）：根本就不能维护的被病态的组合在一起的组件
* （Staralised schema）：指这样的数据库方案，包含了两种用途的表，一是通用的，另
一种是有针对性的
[1.5.1 面向对象设计的反面模式]
* 贫血的域模型（Anemic Domain Model）：仅因为每个对象都要有属性和方法，而在使用
域模型的时候没有加入非OOP的业务逻辑
* （BaseBean）：继承一个工具类，而不是代理它
* 调用父类（Call super）：需要子类调用父类被重载的方法
* 圆还是椭圆问题（Circle-ellipse problem）：基于变量的子类化关系进行子类化（原句
是Subtyping variable-types on the basis of value-subtypes）
* 空子类的错误（Empty subclass failure）：创建不能通过“空子类测试”的类，因为它
和直接从它继承而来没有做其它任何修改的子类表现得不同
* 上帝对象（God object）：在设计的单一部分（某个类）集中了过多的功能
* 对象粪池（Object cesspool）：复用那些不满足复用条件的对象
* 不羁的对象（Object orgy）：没有成功封装对象，外部可以不受限制地访问它的内部
* 幽灵（Poltergeists）：指这样一些对象，它们唯一的作用就是把信息传给其它对象
* 顺序耦合（Sequential coupling）：指这样一些对象，它们的方法必须要按某种特定顺
序调用
* 单例爱好者（Singletonitis）：滥用单例（singleton）模式
* 又TMD来一层（Yet Another Fucking Layer）：向程序中添加不必要的层次结构、库或是
框架。自从第一本关于编程的模式的书出来之后这就变得很普遍。
* 唷唷问题（Yo-yo problem）：一个结构（例如继承）因为过度分裂而变得难于理解
[1.6 编程方面的反面模式]
* 意外的复杂度（Accidental complexity）：向一个方案中引入不必要的复杂度
* 积累再开火（Accumulate and fire）：通过一系列全局变量设置函数的参数
* 在远处行动（Action at distance）：意料之外的在系统分离的部分之间迭代
* 盲目信任（Blind faith）：缺乏对bugfix或子函数返回值的正确性检查
* 船锚（Boat anchor）：在系统中保留无用的部分
* bug磁铁（Bug magnet）：指很少被调用以至于最容易引起错误的代码，或是易出错的构
造或实践
* 忙循环（Busy spin）：在等待的时候不断占用CUP，通常是因为采用了重复检查而不是适
当的消息机制
* 缓存失败（Caching failure）：错误被修正后忘记把错误标志复位
* 货运崇拜编程（Cargo cult programming）：在不理解的情况下就使用模式和方法
* 检查类型而不是接口（Checking type instead of interface）：仅是需要接口符合条件
的情况下却检查对象是否为某个特定类型。可能导致空子类失败
* 代码动力（Code momentum）：过于限制系统的一些部分，因为在其它部分反复对这部分
的内容做出假设
* 靠异常编程（Coding by exception）：当有特例被发现时才添加新代码去解决
* 隐藏错误（Error hiding）：在显示给用户之前捕捉到错误信息，要么什么都不显示，要
么显示无意义的信息
* 异常处理（Expection handling）：使用编程语言的错误处理系统实现平常的编程逻辑
* 硬编码（Hard code）：在实现过程中对系统环境作假设
* 熔岩流（Lava flow）：保留不想要的（冗余的或是低质量的）代码，仅因为除去这些代
码的代价太高或是会带来不可预期的结果
* loop-switch序列（Loop-switch sequence）使用循环结构来编写连续步骤而不是switch
语句
* 魔幻数字（Magic numbers）：在算法里直接使用数字，而不解释含义
* 魔幻字符串（Magic strings）：直接在代码里使用常量字符串，例如用来比较，或是作
为事件代码
* 猴子工作（Monkey work）：指在一些代码复用性或设计上很差的项目中的反复出现的支
持性的代码。通常会被避免或是匆忙完成，因此易于出错，有可能会很快变为bug磁铁。
* Packratting：由于长时间不及时释放动态分配的内存而消耗了过量的内存
* 类似保护（Parallel protectionism）：随着代码变得复杂和脆弱，很容易就克隆出一个
类似的的结构，而不是直接往现有的结构中添加一些琐碎的属性
* 巧合编程（Programming by accident）：尝试用试验或是出错的方式解决问题，有时是
因为很烂的文档或是一开始就没把东西搞清楚
* 馄饨代码（Ravioli code）：系统中有许多对象都是松散连接的
* 软代码（Soft code）：在配置文件里保存业务逻辑而不是在代码中
* 面条代码（Spaghetti code）：指那些结构上完全不可理解的系统，尤其是因为误用代码
结构
* 棉花里放羊毛（Wrapping wool in cottom）：常见的情况是某些类的方法只有一行，就
是调用框架的代码，而没有任何其它有用的抽象
[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报告
[1.8 测试反面模式]
* 敌意测试（hostile testing）：对抗实际的开发方案，使用过量的测试
* 自身测试（Meta-testing）：过度设计测试过程以至于它本身都需要测试，也被称为“看
门人的看门人”
* 移动标的（Moving target）：连续修改设计和实现从而逃避现现有的测试过程
* 奴隶测试（Slave testing）：通过发匿名电邮或贿赂的方式控制测试人员，从而达到股
东的要求
[1.9 配置管理反面模式]
* 依赖的地狱（Dependency hell）：需要的产品的版本导致的问题
* 路径地狱（Classpath hell）：和特定库有关的问题，例如依赖关系和要满足程序运行
所需的版本
* 扩展冲突（Extension conflict）：苹果系统在Mac OS X版本之前的不同扩展的问题
* DLL地狱（DLL hell）：不同版本带来的问题，DLL可见性和多版本问题，在微软的
Windows上尤为突出
* JAR地狱（JAR hell）：JAR文件不同版本或路径带来的问题，通常是由于不懂类加载模
型导致的