反模式[中英文版]

来自Wikipedia, 自由百科全书

在软件工程中，一个反面模式（anti-pattern或antipattern）指的是在实践中明显出现但
又低效或是有待优化的设计模式。

Andrew Koenig在1995年造了anti-pattern这个词，灵感来自于GoF的《设计模式》一书。而
这本书则在软件领域发明了“设计模式”（design pattern）一词。三年后antipattern因
《AntiPatterns》这本书而获得普及，而它的使用也从软件设计领域扩展到了日常的社会互
动中。按《AntiPatterns》作者的说法，可以用至少两个关键因素来把反面模式和不良习惯
、错误的实践或糟糕的想法区分开来：

* 行动、过程和结构中的一些重复出现的乍一看是有益的，但最终得不偿失的模式
* 在实践中证明且可重复的清晰记录的重构方案

很多反面模式只相当于是错误、咆哮、不可解的问题、或是可能可以避免的糟糕的实践，它
们的名字通常都是一些用反话构成的词语。有些时候陷阱（pitfalls）或黑色模式（dark
patterns）这些不正式的说法会被用来指代各类反复出现的糟糕的解决方法。因此，一些有
争议的候选的反面模式不会被正式承认。

原文：http://en.wikipedia.org/wiki/Anti-pattern
译文：http://blog.csdn.net/KornerHill


[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文件不同版本或路径带来的问题，通常是由于不懂类加载模
    型导致的

 

=============================================================

Anti-pattern

From Wikipedia, the free encyclopedia

  (Redirected from Antipattern)

Jump to: navigation, search

<!---->

For the book, see AntiPatterns.

In software engineering, an anti-pattern (or antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice.^[1][2]

The term was coined in 1995 by Andrew Koenig,^[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software design and into general social interaction. According to the authors of the latter, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:

• Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and
• A refactored solution that is clearly documented, proven in actual practice and repeatable.

Often pejoratively named with clever oxymoronic neologisms, many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible. Sometimes called pitfalls or dark patterns, this informal use of the term has come to refer to classes of commonly reinvented bad solutions to problems. Thus, many candidate anti-patterns under debate would not be formally considered anti-patterns.

By formally describing repeated mistakes, one can recognize the forces that lead to their repetition and learn how others have refactored themselves out of these broken patterns.

<script type="text/javascript"></script>

[edit] Known anti-patterns

[edit] Organizational anti-patterns

• Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
• Cash cow: A profitable legacy product that often leads to complacency about new products
• Cost migration: Transfer of project expenses to a vulnerable department or business partner
• Crisis mode (a.k.a firefighting mode): Dealing with things only when they become a crisis, with the result that everything becomes a crisis
• Design by committee: The result of having many contributors to a design, but no unifying vision
• Escalation of commitment: Failing to revoke a decision when it proves wrong
• Management by neglect: Too much delegation
• Management by numbers: Paying excessive attention to quantitative management criteria, when these are non-essential or cost too much to acquire
• Management by perkele: Authoritarian style of management with no tolerance for dissent
• Management by wondering: Expecting a team to define their own objectives, and then wondering what they're doing
• Milk Monitor Promotion: A pseudo promotion (a better sounding title), with no additional responsibilities or pay increase, which is given as a quick and costless way to make the employee work harder.^[clarify]
• Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
• Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
• Stovepipe: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
• Vendor lock-in: Making a system excessively dependent on an externally supplied component
• Violin string organization: A highly tuned and trimmed organization with no flexibility

[edit] Project management anti-patterns

• Death march: Everyone knows that the project is going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang")
• Smoke and mirrors: Demonstrating how unimplemented functions will appear
• Software bloat: Allowing successive versions of a system to demand ever more resources

[edit] Team management anti-patterns

• Cage match negotiator: When a manager uses a "victory at any cost" approach to management.
• Doppelganger: A manager or colleague who can be nice and easy to work with one moment, and then vicious and unreasonable the next.
• Fruitless hoops: The manager who requires endless (often meaningless) data before making a decision.
• Headless chicken: The manager who is always in a panic-stricken, fire-fighting mode.
• Leader not manager: The manager who is a good leader, but lacks in their administrative and managerial ability.
• Managerial cloning: The hiring and mentoring of managers to all act and work the same: identically to their bosses.
• Manager not leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability.
• Mr. nice guy: The manager that strives to be everyone’s friend.
• Proletariat hero: The "everyman" worker who is held up as the ideal, but is really just a prop for management's increasing demands and lengthening production targets.
• Rising upstart: The potential stars who can’t wait their time and want to forgo the requisite time to learn, mature and find their place.
• Seagull management (hit-and-run management): The manager flies in, makes a lot of noise, craps all over everything, then flies away.
• Three-headed knight: The indecisive manager.
• Ultimate weapon: Phenomena that are relied upon so much by their peers or organization that they become the conduit for all things.
• Yes man: The manager who will agree with everything the CEO says, but changes mind away from his presence.

[edit] Analysis anti-patterns

• Napkin specification: The Functional/Technical specification is given to the Development team on a napkin (i.e., informally, and with insufficient detail) which is fundamentally equivalent to having no specification at all.
• Phony requirements: All requirements are communicated to the development teams in a rapid succession of netmeeting sessions or phone calls with no Functional/Technical specification or other supporting documentation.
• Retro-specification: To write the Technical/Functional specification after the project has already gone live.

[edit] Software design anti-patterns

 

• Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
• Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
• Big ball of mud: A system with no recognizable structure
• Blob: Generalization of God object from object-oriented design
• Gas factory: An unnecessarily complex design
• Input kludge: Failing to specify and implement handling of possibly invalid input
• Interface bloat: Making an interface so powerful that it is extremely difficult to implement
• Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
• Race hazard: Failing to see the consequence of different orders of events
• Railroaded solution: A proposed solution that while poor, is the only one available due to poor foresight and inflexibility in other areas of the design
• Re-coupling: Introducing unnecessary object dependency
• Stovepipe system: A barely maintainable assemblage of ill-related components
• Staralised schema: A database schema containing dual purpose tables for normalised and datamart use

[edit] Object-oriented design anti-patterns

• Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
• BaseBean: Inheriting functionality from a utility class rather than delegating to it
• Call super: Requiring subclasses to call a superclass's overridden method
• Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
• Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
• God object: Concentrating too many functions in a single part of the design (class)
• Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
• Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
• Poltergeists: Objects whose sole purpose is to pass information to another object
• Sequential coupling: A class that requires its methods to be called in a particular order
• Singletonitis: The overuse of the singleton pattern
• Yet Another Useless Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.
• Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

[edit] Programming anti-patterns

• Accidental complexity: Introducing unnecessary complexity into a solution
• Accumulate and fire: Setting parameters for subroutines in a collection of global variables
• Action at a distance: Unexpected interaction between widely separated parts of a system
• Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
• Boat anchor: Retaining a part of a system that no longer has any use
• Bug magnet: A block of code so infrequently invoked/tested that it will most likely fail, or any error-prone construct or practice.
• Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
• Caching failure: Forgetting to reset an error flag when an error has been corrected
• Cargo cult programming: Using patterns and methods without understanding why
• Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required. May cause Empty subclass failure.
• Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
• Coding by exception: Adding new code to handle each special case as it is recognized
• Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
• Expection handling: (From Exception + Expect) Using a language's error handling system to implement normal program logic
• Hard code: Embedding assumptions about the environment of a system at many points in its implementation
• Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
• Loop-switch sequence: Encoding a set of sequential steps using a loop over a switch statement
• Magic numbers: Including unexplained numbers in algorithms
• Magic strings: Including literal strings in code, for comparisons, as event types etc.
• Monkey work: Term for any general repeated support code required within projects which suffer from poor code reuse and design. Is often avoided and rushed, hence open to errors and can quickly become a Bug magnet.
• Packratting: Consuming excessive memory by keeping dynamically allocated objects alive for longer than they are needed
• Parallel protectionism: When code becomes so complex and fragile that it is easier to clone a parallel infrastructure than to add a trivial attribute to existing infrastructure
• Programming by accident: Trying to solve problems by trial and error, sometimes because of poor documentation or not thinking things out first.
• Ravioli code: Systems with lots of objects that are loosely connected
• Soft code: Storing business logic in configuration files rather than source code^[4]
• Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
• Wrapping wool in cotton: Commonly observed when framework methods are contained in single line methods in wrapper classes which provide no useful abstraction

[edit] Methodological anti-patterns

• Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
• De-factoring: The process of removing functionality and replacing it with documentation
• Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
• Improbability factor: Assuming that it is improbable that a known error will occur
• Low hanging fruit: Dealing with easier issues first while ignoring larger more complex issues. It can be thought of as to the relative ease with which scientific, philosophical and technological discoveries are made at first compared with the difficulties once the subject has already been explored.^[clarify]
• Not built here : See: Reinventing the wheel, Not invented here.
• Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
• Programming by permutation: Trying to approach a solution by successively modifying the code to see if it works
• Reinventing the square wheel: Creating a poor solution when a good one exists
• Reinventing the wheel: Failing to adopt an existing, adequate solution
• Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
• Tester driven development: Software projects where new requirements are specified in bug reports

[edit] Testing anti-patterns

• Hostile testing: Antagonizing practical development solutions and workflow with over-testing procedures or over-scheduling test runs
• Meta-testing: Overdesigning testing procedures until it is necessary to test them, also known as "watchmen's watchmen"
• Moving target: Continuously change design and/or implementation in order to escape established testing procedures

[edit] Configuration management anti-patterns

• Dependency hell: Problems with versions of required products
• Classpath hell: Problems related to specifying Java libraries, their dependencies and their required version to run the application
• Extension conflict: Problems with different extensions to pre-Mac OS X versions of the Mac OS attempting to patch the same parts of the operating system
• DLL hell: Overutilization of the dynamic-link libraries (DLLs), specifically on Microsoft Windows
• JAR hell: Overutilization of the multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model

[edit] See also

• Code smell – symptom of unsound programming
• List of software development philosophies – approaches, styles, maxims and philosophies for software development
• Service-Oriented Modeling Framework (SOMF)

[edit] References

1. ^ Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley, pp. 225. ISBN 0-201-72219-4.  "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
2. ^ Ambler, Scott W. (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press, pp. 4. ISBN 0-521-64568-9.