关注产品和项目开发中的反模式

 设计模式是一个被大家熟知的话题,但是熟悉“反模式”的人就很少了,其实,从字面讲,反模式也就是一些经过惨痛教训总结出来的,被公认为不是很好的方法和行为,请在你的开发实践中,尽量避免出现这样的问题,因为很容易导致失败和错误哦!

维基百科对“反模式”的定义如下:

在实践中明显出现但又低效或是有待优化的设计模式,是用来解决问题的带有共同性的不良方法。

反模式分为如下几类(来自维基百科):

社会和组织结构

组织结构

  • 分析瘫痪(Analysis paralysis):花费太多精力在项目的分析阶段
  • 摇钱树(cash cow):盈利的老产品通常会导致对新产品的自负
  • 委员会设计(Design by committee):很多人同时进行设计,却没有统一的看法
  • 承诺升级(Escalation of commitment):明知错了还不能收回之前的决定
  • 独裁管理(Management by perkele):用完全听不进异议的独裁作风进行管理
  • 目标管理(Management by objectives):通过数字管理,过于关注非本质而或不易取得的数字指标
  • 道德风险(Moral hazard):不让做决定的人知道他的决定会带来什么结果
  • 蘑菇管理(Mushroom management):不通知或是错误地通知雇员信息。雇员像蘑菇一样在黑暗中吸取养分,自生自灭
  • 烟囱或者发射塔(Stovepipe or Silos):结构上支持数据主要在上下方面的流动,却禁止跨部门的通信
  • 供应商套牢(Vendor lock-in):使一个系统过于依赖外部提供的部件

项目管理

  • 雪崩模型(Avalanche):不合理的混合瀑布模型和敏捷开发
  • 死亡征途(Death march):除了CEO, 每个人都知道这个项目会成为一场灾难,但是真相却被隐瞒下来,以免项目被立即取消。(尽管CEO通常知道并且仍然继续试图最大化利润。)然而,真相被隐藏 起来,直到大限来临 ("Big Bang")。另一种定义:雇员由于不合理的deadline,被迫在深夜和周末加班。
  • 团队思维(Groupthink):在团队思维中,团队成员避免提出在一致观点之外的思维。
  • 过度设计(Overengineering):花费资源完成比实际需要的还要鲁棒和复杂的工程
  • 障眼法(Smoke and mirrors):展示还没实现的功能,就像它们已经实现了一样
  • 软件膨胀(Software bloat):允许系统的后续版本使用更多的资源

分析方式

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

软件工程

软件设计

  • 抽象倒置(Abstraction inversion):不把用户需要的功能直接提供出来,导致他们要用更上层的函数来重复实现
  • 用意不明(Ambiguous viewpoint):给出一个模型(通常是OOAD,面向对象分析与设计)却没有指出用意何在
  • 大泥球(Big ball of mud):没有清晰结构的系统
  • 用数据库进行进程间通信(Database-as-IPC):使用数据库进行进程间通信,而不使用更轻量级的合适的机制。
  • 镀金(Gold plating):在项目达到最高价值后还继续工作。
  • 内部平台效应(Inner-platform effect):系统可自定义的太多,以至于成为一个软件开发平台的蹩脚的复制品。
  • 输入问题(Input kludge):无法确定和实现对异常输入的处理
  • 接口膨胀(Interface bloat):把一个接口做得过于强大以至于极其难以实现
  • 魔力按键(Magic pushbutton):直接在接口的代码里编写实现,而不使用抽象
  • 竞争风险(Race hazard):输出结果受到事件执行顺序和时机的影响,在多线程环境和分布式系统中可能发生
  • 烟囱系统(Stovepipe system):过度聚集数据和功能,忽视了与其他系统和模块的共享

面向对象设计

  • 贫血的域模型(Anemic Domain Model):仅因为每个对象都要有属性和方法,而在使用域模型的时候没有加入非OOP的业务逻辑
  • (BaseBean):继承一个工具类的功能,而不是委托给它
  • 调用父类(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):意料之外的在系统分离的部分之间交互
  • 盲目信任(Blind faith):缺乏对bugfix的校验或对子函数返回值的正确性检查
  • 船锚(Boat anchor):在系统中保留无用的部分
  • 忙等待(Busy waiting):在等待的时候不断占用CPU,通常是因为采用了重复检查而不是适当的消息机制
  • 缓存失败(Caching failure):错误被修正后忘记把错误标志复位
  • 拜物编程(Cargo cult programming):由于对模式的盲目崇拜,在不理解的情况下就使用模式和方法,企图得到好的结果
  • 靠异常编程(Coding by exception):当有特例被发现时才添加新代码去解决
  • 隐藏错误(Error hiding):在显示给用户之前捕捉到错误信息,要么什么都不显示,要么显示无意义的信息
  • 硬编码(Hard code):将对系统环境的假设写入实现中
  • 熔岩流(Lava flow):保留不想要的(冗余的或是低质量的)代码,仅因为除去这些代码的代价太高或是会带来不可预期的结果
  • 循环-switch序列(Loop-switch sequence):在循环结构中使用switch语句来编写连续步骤
  • 魔幻数字(Magic numbers):在算法里直接使用数字,而不解释含义
  • 魔幻字符串(Magic strings):直接在代码里使用常量字符串,例如用来比较,或是作为事件代码
  • 软代码(Soft code):在配置文件里保存业务逻辑而不是在代码中
  • 面条代码(Spaghetti code):指那些结构上完全不可理解的系统,尤其是因为误用代码结构
  • 霰弹枪手术(Shotgun surgery):开发人员一次性在一个多个实现的代码基中增加功能

方法论

  • 拷贝粘贴编程(Copy and paste programming):拷贝(然后修改)现有的代码而不是构造通用的解决方案
  • 黄金大锤(Golden hammer):认为自己最喜欢的解决方案是到处通用的(见:银弹)
  • 不可能因素(Improbability factor):认为已知的错误不可能发生
  • 不是这里发明的(Not invented here):拒绝使用组织外的主意或方案
  • 这里发明的(invented here):拒绝组织内部实现的创新或解决方案,通常因为对成员没有信心
  • 不成熟的优化(Premature optimization):在编码的早期追求代码的效率,牺牲了好的设计、可维护性、有时甚至是现实世界的效率
  • 转换编程法巧合编程(Programming by permutation or programming by accident):试图通过连续修改代码再看是否工作的方式来解决问题
  • 重新发明方的轮子(Reinventing the square wheel):已经有一个很好的方案了,又再搞一个烂方案来替代它
  • 银弹(Silver bullet):认为自己最喜欢的技术方案能解决一个更大的问题
  • 测试人员驱动开发(Tester driven development):需求来自bug报告的软件工程

配置管理

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

猜你喜欢

转载自windshome.iteye.com/blog/1840651