`
fxly0401
  • 浏览: 148760 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

反面模式(Anti-pattern)

 
阅读更多
原文:http://en.wikipedia.org/wiki/Anti-pattern
译文:http://www.yeeyan.com/articles/view/27472/7244


[前言]

design pattern是设计模式,通常是前人在软件开发过程中积累出来的解决一些问题的现成套路,按它们来做可获益无穷。anti-pattern也是一些现成的套路,但它们是现成的错误套路,避免它们则亦可获益无穷。本文译者Korner Hill的更多其它翻译和原创文章可在blog上找到http://blog.csdn.net/KornerHill。

计算机领域内的很多词汇都缺少公认的中文翻译,anti-pattern也是如此,这里译为反面模式,乃是因为它本身是作为反面教材使用的模式。其实直接用“反面教材”更通俗易懂,但这里为了保持它与设计模式之间的内在关联,而使用了“反面模式”一词。

文中有些个别单词没有翻译,一是如bug和bugfix这样在计算机领域内已经广泛使用的词,二是像Staralised这种在字典里都查不到词,三是像perkele这种有文化背景的名字(perkele是芬兰神话里的雷神)。

有些地方即使翻译过来,可能读者还是不一定会明白,毕竟代码的事情不是纸上谈兵。例如Circle-ellipse problem,涉及的概念较多,虽然能翻译过来,但读者若要理解,还是得到wikipedia上再查。

翻译这篇文章确实很不容易,既要英文好,又要有编程的背景,最好还要有西方生活的背景,在下水平有限,很多地方翻译不到位,请各们谅解。


================================================================================
= 以下是译文部分
================================================================================

来自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://www.yeeyan.com/articles/view/27472/7244

[目录]
[1. 已知的反面模式]
[1.1 组织结构的反面模式]
[1.2 项目管理的反面模式]
[1.3 团队管理的反面模式]
[1.4 分析方式的反面模式]
[1.5 通常的设计反面模式]
[1.5.1 面向对象设计的反面模式]
[1.6 编程方面的反面模式]
[1.7 方法学上的反面模式]
[1.8 测试反面模式]
[1.9 配置管理反面模式]

[Contents]
[1 Known anti-patterns]
[1.1 Organizational anti-patterns]
[1.2 Project management anti-patterns]
[1.3 Team management anti-patterns]
[1.4 Analysis anti-patterns]
[1.5 Software design anti-patterns]
[1.5.1 Object-oriented design anti-patterns]
[1.6 Programming anti-patterns]
[1.7 Methodological anti-patterns]
[1.8 Testing anti-patterns]
[1.9 Configuration management anti-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文件不同版本或路径带来的问题,通常是由于不懂类加载模型导致的
分享到:
评论

相关推荐

    安全架构-反模式白皮书.rar

    anti-pattern 没想到什么好词,且就叫反面模式 反模式1:‘Browse-up’ for administration(浏览模式管理的不安全性) Unfortunately it is all too common to see ‘browse-up’ approaches to administering ...

    ANTI-VeaD:分心器的交互和警惕性注意网络测试(执行和唤醒组件)的分析(ANTI-VeaD)

    反面 注意力吸引器交互和警惕性测试网络(执行和唤醒组件)的分析(ANTI-VeaD)。 该项目包括: 一个输入:“ Data_ANTI-VeaD.xlsx”。 该文件是由E-Prime 2.0生成的,包含了ANTI-VeaD中117位参与者的分数。 两个...

    opencv-python、pytesseract身份证识别,正面、反面

    使用opencv-python +pytesseract 身份证识别正反面,包含姓名、身份证号、性别、详细地址。 1、所需库:pytesseract.py 安装:pip3 install pytesseract pip3 install opencv-python==3.4.8.29 2、中文文字识别...

    Android-身份证正反面识别身份证扫描识别离线无需联网极速秒扫

    标题"Android-身份证正反面识别身份证扫描识别离线无需联网极速秒扫"所描述的就是一个这样的功能,它利用OCR(Optical Character Recognition,光学字符识别)技术,能够快速准确地识别身份证正反两面的所有信息,...

    [改变课堂教学模式--培养学生创新思维]-如何培养创新思维.docx

    在数学证明或问题解决过程中,教师应指导学生尝试从反面思考问题,通过反例验证命题,或转换问题的角度。例如,在探讨两个量之间的倍数关系时,可以引导学生同时思考A是B的5倍与B是A的几分之一之间的关系。通过逆向...

    USB-C可选模式应用

    - **正反插功能**:无需区分正反面,简化了用户的使用体验。 - **高电力传输**:支持最高100W的电力传输能力,满足快充等高功率需求。 - **多协议兼容性**:能够在单一接口上传输数据、视频信号、电力等,提高了设备...

    物体的正反面识别(图像处理)

    对于纹理,可以利用Gabor滤波器或LBP(局部二值模式)来描述。色彩特征则可通过HSV或Lab色彩空间进行分析。选择合适的特征有助于区分物体正反面的细微差异。 接着,机器学习和深度学习技术在物体正反面识别中扮演着...

    电信设备-反面式信封.zip

    《电信设备-反面式信封》这一压缩包文件,主要包含了一份名为“反面式信封.pdf”的文档,从其命名来看,我们可以推测这份资料可能与电信行业中的一种特殊信封设计有关,可能是用于邮寄或者封装电信设备的专用信封。...

    2-1 ATTEMPT记录表-反面注释版SOP.pdf

    2-1 ATTEMPT记录表-反面注释版SOP

    利用Java进行身份证正反面信息识别

    本文将详细介绍如何利用Java语言结合百度提供的库实现身份证正反面信息的自动识别。 首先,我们需要了解身份证信息识别的基本流程。这通常包括图像采集、预处理、特征提取和识别四个步骤。在Java环境中,我们可以...

    Java进行身份证正反面信息识别.rar

    本资源“Java进行身份证正反面信息识别.rar”提供了一种利用Java编程语言结合百度提供的库来实现身份证信息读取的方法。下面将详细阐述相关知识点。 1. **身份证信息识别**:身份证信息识别是指通过技术手段自动...

    PDF文件正反面扫描,操作很方便

    有时候我们需要将多页的纸质文档正反面扫描成一个PDF文件,以方便存储和传输。"PDF文件正反面扫描合并"这个主题就是针对这一需求,提供了一种高效便捷的方法来完成任务。 首先,我们要理解PDF文件的合并过程。PDF...

    模拟硬币正反面数理统计方法

    图解消费者需求(罗兰贝格).pdf

    该工具通过图表形式,将复杂的消费者心理和行为模式直观呈现,便于企业决策者快速掌握关键信息。 在罗兰贝格的消费者需求图解中,核心概念围绕“价值主张”展开。价值主张(Value Proposition)是企业向目标客户传递...

    行业文档-设计装置-纸张的正反面熨平装置.zip

    "纸张的正反面熨平装置"是一种专为处理纸张平整度问题而设计的机械设备,它在印刷、包装以及文档处理等领域有着广泛的应用。这个装置的主要目的是消除纸张上的皱褶和不平整,以确保打印质量或者后续加工的精准性。 ...

    京瓷300i复印机身份证正反面复印方法知识.pdf

    2. 选择身份证复印模式,选择正面或反面复印。 3. 选择纸张尺寸和复印质量,根据需要选择合适的纸张尺寸和复印质量。 4. 将身份证放在复印机的扫描台上,等待机器扫描。 5. 等待机器完成复印,最后点“复位”键。 ...

    正反面翻转举例.html

    简单的正反面翻转效果, 背面不可见

    行业文档-设计装置-一种控制装饰原纸正反面的装置.zip

    标题中的"一种控制装饰原纸正反面的装置"很可能是一个自动化生产线上的设备,用于确保装饰原纸在生产过程中的正反面正确无误。这种装置可能结合了传感器、微控制器、机械传动和控制系统等技术。 装饰原纸是一种广泛...

    博弈论小结by xaphoenix

    例如,Anti-SG是SG游戏的反面,其胜利状态与SG相反。 文章还讨论了三类经典的SG游戏:放硬币游戏、图游戏和无向图删边游戏。这些游戏通常涉及到图论和组合优化,玩家需要在图形结构中做出选择以达到胜利。 最后,...

    opengl造型设计

    `:设置反面为线形模式。 - `glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);`:设置两面均为顶点模式。 - **正反面设置**:默认情况下,“顶点以逆时针顺序出现在屏幕上的面”为“正面”,另一个面为“反面”。可以...

Global site tag (gtag.js) - Google Analytics