跳转到内容

反面模式

维基百科,自由的百科全书

软件工程中,反面模式(anti-pattern或antipattern)指的是在实践中經常出现但又低效或是有待优化的设计模式[1][2],是用来解决问题的带有共同性的不良方法。它们已经经过研究并分类,以防止日后重蹈覆辙,并能在研发尚未投产的系统时辨认出来。

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

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

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

这个概念很容易推广到工程学以及工程以外需要人们付出努力去争取的领域。尽管在工程学以外很少用到这个术语,但其概念是通用的。

举例

社会和组织结构

组织结构

  • 分析癱瘓(Analysis paralysis):花费太多精力在项目的分析阶段
  • 腳踏車棚(Bicycle shed):對於一些不重要的事務花上不成比例的精力
  • 超前沿技術(Bleeding edge,刀锋):采用一些未经测试和/或尚不稳定的前沿技术来运营,从而导致成本超支、表现/性能不佳,和/或交付延期。
  • 摇钱树英语Cash cow(cash cow):假如舊产品的盈利能力強,通常会导致企業沒有動力開發新产品
  • 委员会设计(Design by committee):很多人同时进行设计,却没有统一的看法
  • 承诺升级(Escalation of commitment):明知错了还不能收回之前的决定
  • 目标管理(Management by objectives):通过数字管理,过于关注非本质而或不易取得的数字指标
  • 道德风险(Moral hazard):不让做决定的人知道他的决定会带来什么结果
  • 蘑菇管理(Mushroom management):不通知或是错误地通知雇员信息。雇员像蘑菇一样在黑暗中吸取养分,自生自灭
  • 海鷗管理(Seagull management):只有当出现问题的时候管理人员才会跟雇员进行接触和互动的管理模式。典型的场景就是,海鸥式的管理人员“飞”过来,嘁嘁喳喳,是人都批评一通,尔后“飞”走了!
  • 烟囱式管理英语Stovepipe or Silos(Stovepipe or Silos,竖井式/发射井式/谷仓式管理):组织结构是由若干彼此孤立的团队组成,并且整个组织结构的范围内,上下沟通交流能够有效进行,而水平/横向的则不然。结构上支持数据主要在上下方面的流动,却禁止跨部门的通信。
  • 厂商陷阱英语Vendor lock-in(Vendor lock-in,供应商套牢,供应商陷阱,厂商泥潭):使一个系统过于依赖于外部所提供的组件/部件。

项目管理

  • 死亡征途英语Death march (project management)(Death march,死亡之旅):除了CEO,每个人都知道这个项目会成为一场灾难,但是真相却被隐瞒下来,以免项目被立即取消。(尽管CEO通常知道并且仍然继续试图最大化利润。)然而,真相被隐藏起来,直到大限来临("Big Bang")。另一种定义:雇员由于不合理的deadline,被迫在深夜和周末加班。
  • 团队思维(Groupthink):在团队思维中,团队成员避免提出在一致观点之外的思维。
  • 九九定律(Ninety-ninety rule):当项目“几近完成”时,低估完成项目所需时间的倾向。
  • 过度设计(Overengineering):花费资源完成比实际需要的还要复杂的工程
  • 障眼法英语Smoke and mirrors(Smoke and mirrors):展示还没实现的功能,就像它们已经实现了一样

分析方式

  • 旁观冷漠(Bystander apathy):一个需求或者设计是错的,注意到这一点的人却不指出,因为这影响的是其他人。

软件工程

软件设计

面向对象设计

  • 贫血的域模型(Anemic Domain Model):仅因为每个对象都要有属性和方法,而在使用域模型的时候没有加入非OOP的业务逻辑
  • 调用父类(Call super):需要子类调用父类被重定义的方法
  • 圆还是椭圆问题(Circle-ellipse problem):基于变量的子类化关系进行子类化
  • 循环依赖(Circular dependency):在对象或软件模块中,直接或间接引入循环依赖。
  • 常量接口(Constant interface):使用接口定义常量
  • 上帝对象(God object):在设计的单一部分(某个类)集中了过多的功能
  • 对象粪池(Object cesspool):复用那些不满足复用条件的对象。对象池是一种管理对象的方法,在重复使用对象前,需要针对对象进行初始化,以避免上次使用后的状态等数据影响下次的使用
  • 不羁的对象(Object orgy):没有成功封装对象,外部可以不受限制地访问它的内部
  • 幽灵(Poltergeists):指这样一些对象,它们唯一的作用就是把信息传给其它对象
  • 顺序耦合(Sequential coupling):指这样一些对象,它们的方法必须要按某种特定顺序调用
  • 悠悠问题(Yo-yo problem):一个结构(例如继承)因为过度碎片化而变得难于理解

编程

  • 偶然复杂度(Accidental complexity):向一个方案中引入不必要的复杂度
  • 遠隔作用(Action at distance):意料之外的在系统分离的部分之间交互
  • 船錨英语Boat_anchor_(metaphor)(Boat anchor):在系统中保留无用的部分
  • 忙等待(Busy waiting):在等待的时候不断占用CPU,通常是因为采用了重复检查而不是适当的消息机制
  • 缓存失败英语Caching failure(Caching failure):错误被修正后忘记把错误标志复位
  • 拜物编程(Cargo cult programming):由于对模式的盲目崇拜,在不理解的情况下就使用模式和方法,企图得到好的结果
  • 靠异常编程英语Coding by exception(Coding by exception):当有特例被发现时才添加新代码去解决
  • 隐藏错误英语Error hiding(Error hiding):在显示给用户之前捕捉到错误信息,要么什么都不显示,要么显示无意义的信息
  • 硬编码(Hard code):将对系统环境的假设写入实现中
  • 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果
  • 循环-switch序列英语Loop-switch sequence(Loop-switch sequence)在循环结构中使用switch语句来编写连续步骤
  • 魔術數字(Magic numbers):在算法里直接使用数字,而不解释含义
  • 魔幻字符串英语Magic string(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码
  • 自我复制(Repeating yourself):通过不断复制已有代码的模式或代码段进行编码;而非采用once and only once(抽取原则)
  • 软代码英语Soft code(Soft code):在配置文件里保存业务逻辑而不是在代码中
  • 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构
  • 霰弹枪手术英语Shotgun surgery(Shotgun surgery):开发人员一次性在一个多个实现的代码基中增加功能

方法论

配置管理

  • 依赖地狱(Dependency hell):所依赖产品的版本所导致的问题
  • DLL地狱(DLL hell):不同版本DLL所带来的问题,包括DLL可见性和多版本问题,在微软的Windows上尤为突出
  • 扩展冲突英语Extension conflict(Extension conflict):苹果系统在Mac OS X版本之前的不同扩展的问题
  • JAR地狱英语JAR hell(JAR hell):JAR文件不同版本或路径带来的问题,通常是由于不懂类加载模型导致的

注释

  1. ^ Budgen, D. Software design. Harlow, Eng.: Addison-Wesley. 2003: pp. 225 [2008-05-05]. ISBN 0-201-72219-4. (原始内容存档于2015-04-14).  "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
  2. ^ Ambler, Scott W. Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. 1998: pp. 4 [2008-05-05]. ISBN 0-521-64568-9. (原始内容存档于2015-04-14).  "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
  3. ^ Koenig, Andrew. Patterns and Antipatterns. Journal of Object-Oriented Programming. March/April 1995, 8, (1): 46–48. 
  4. ^ Rising, Linda. The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. 1998: pp.387 [2008-05-05]. ISBN 0-521-64818-1. (原始内容存档于2015-04-15). 

参考文献

  • Perl設計模式–一部開放的線上書籍。
  • Brown, William J.; Raphael C. Malveau, Hays W. McCormick III,和Thomas J. Mowbray. 反模式:软件重构、架构及项目危机. John Wiley & Sons. 1998. ISBN 978-0-471-19713-3. 
  • Laplante, Phillip A.; and Colin J. Neill. Antipatterns: Identification, Refactoring and Management. Auerbach Publications. 2005. ISBN 978-0-8493-2994-4. 

外部链接