软件开发性反模式

来自随意问技术百科
跳转至: 导航搜索

The Blob(胖球)

程序风格的设计导致一个对象集中了过多的功能,而其他的对象只用来保存数据或者执行一些简单的过程。解决的办法是,对设计进行重构,使功能平均的分散开,从而将某一变动带来的的影响限制在一定的范围内。

反模式名称:The Blob

别名:Winnebago、The God Class

最常见规模:应用层

重构方案名称:Refactoring of Responsibilities(职责重构)

重构方案类型:软件

根源:懒惰、匆忙

不平衡的力量:功能管理、性能管理、复杂性管理

轶事证据:“这个类确实是我们的心脏”

Continuous Obsolescence(持续过时)

技术变化非常迅速,以至于开发人员往往难以跟上软件的当前版本,无法找到可以共同工作的产品发布的组合.体会:关于第三方的软件版本在项目中一定要统一,曾经在一个项目开发过程中发现运行效果不一致,最终确认是JDK版本问题.

Lava Flow(岩浆流)

死代码和被遗忘的设计信息会冻结在不断变化的设计中.体会:每次进行较大修改时,习惯性保留原有代码以备后用,但事实表明死代码再未使用,只会增加后来者的困惑.我想随着技术的进步,死代码复活的可能性很小,建议在最新版本中及时清除,可在版本控制中保留.

反模式名称:Lava Flow

别名:Dead Code

最常见规模:应用层

重构方案名称:Architectural Configuration Management(架构配置管理)

重构方案类型:过程

根源:贪婪、懒惰

不平衡的力量:功能管理、性能管理、复杂性管理

轶事证据:“哦,那些啊。Ray和Emil(他们已经不在这个公司了)写了那段例程,当时Jim(他上个月离开了)正在尝试绕过Irene(她现在也去了另一个部门)的输入处理代码。我想现在没地方还使用它,不过我也不确定。Irene并没有很清楚地给它写文档,所以我们估计现在还是应该让它保持原样。毕竟这东西可以工作,不是吗?”

Ambiguous Viewpoint(模糊视角)

面向对象的分析和设计模型通常没有指明其用意何在。在默认的情况下,OOA&D的模型只指明了一个最无关紧要的用意。混合式的意图则不允许用户界面同实现细节在原则上相分离,这正是面向对象带给我们的好处。

Functional Decomposition(功能分解)

这个反模式是有经验的不适用面向对象方法的开发着用一门面向对象语言设计和实现一个应用程序时的产物。生成的代码类似于把一门结构化的语言放进一个类结构中。当一个自作聪明的程序员用一种非常“聪明”的方式把这种费时的方法带进一个面对对象的架构中时,这个架构将非常的复杂。

反模式名称:Functional Decomposition

别名:No Object-Oriented AntiPattern(非面向对象反模式)、“No OO”(非面向对象)

最常见规模:应用层

重构方案名称:Object-Oriented Reengineering(面向对象再设计)

重构方案类型:过程

根源:贪婪、懒惰

不平衡的力量:复杂性管理、变化管理

轶事证据:“这是我们的‘主’例程,在这个名为LISTENER(监听器)的类中。”

Poltergeist(恶作剧鬼)

幽鬼是指那些作用有限,有效执行期短的类。它们只为一些对象执行一些初始化程序。可重构的解决方案是将功能分配给一个生存期长的对象,从而消除幽鬼。

反模式名称:Poltergeist

别名:Gypsy、Proliferation of Classes(类增殖)、Big Dolt Controller Class

最常见规模:应用层

重构方案名称:Ghosbusting(捉鬼)

重构方案类型:过程

根源:懒惰、无知

不平衡的力量:功能管理、复杂性管理

轶事证据:“我不确定这个类到底做什么,但它肯定很重要!”

Boat Anchor(船锚)

它是指在当前项目中没有起到有益作用的那些软件或硬件。体会:反面的例子我没有看到。但正面的例子却值得去延续,在某个项目中,用户不断反馈对各项新功能的赞赏,开发团队的情绪也随之高涨,所以新增功能上线后,收集正面反馈也是有必要的。

Golden Hammer(金锤)

它是指把一种熟悉的技术或概念强迫性地应用于许多软件问题。体会:典型案例是在某项目开发过程中,开发商对于存储过程非常熟悉,众多解决方案都用存储过程实现,虽然有些做了纠正,但最终比例还是相当大。

反模式名称:Golden Hammer

别名:Old Yeller、Head-in-the sand(鸵鸟政策)

最常见规模:应用层

重构方案名称:Expand your horizons(扩展视线)

重构方案类型:过程

根源:无知、自负、思想狭隘

不平衡的力量:技术转移管理

轶事证据:“我有一个锤子,所以所有东西就都是钉子。”“我们的数据库就是我们的架构。”“也许我们根本就不应该使用Excel宏来做这件事。”

Dead End(死胡同)

如果对一个可复用构件进行修改后它不再受供应商的支持,那么对它的修改就会形成Dead End.体会:购买的通用产品完全依赖于提供商的支持就不说了,开发商不再负责维护的代码确实令人头痛,最好的可能就是升级换代时整体推翻。

Spaghetti Code(面条代码)

即兴生成的软件结构导致难以扩展和优化代码。体会:这里重点强调数据库结构的设计,从几个项目来看,数据库设计评审是非常重要,直接影响到设计的实现。在这点上,吃过亏,也取得很大的成效。

反模式名称:Spaghetti Code

最常见规模:应用层

重构方案名称:Software Refactoring(软件重构)、Code Cleanup(代码清理)

重构方案类型:软件

根源:无知、懒惰

不平衡的力量:复杂性管理、变化管理

轶事证据:“啊!真乱哪!”“你确定知道这种语言支持不只一个函数,不是吗?”“重写这段代码比试着修改它更容易。”“软件工程师不写Spaghetti Code。”“你的软件结构的质量是为将来的修改和扩展进行的投资。”

Input Kludge(输入拼凑)

未能通过直接行为测试的软件可能就是Input Kludge的例子。体会:这种行为是很难通过验收测试检查出来的,发生实际问题时常会发现这就一个低级错误,关键看开发者的责任心了。

Walking through a Mine Field(穿越雷池)

Cut-And-Paste Programming(剪贴编程)

通过剪贴语句形成的代码复用会导致显著的维护问题。体会:道理大家都知道,但做起来还是剪贴来得方便。

反模式名称:Clipboard Coding(剪切板编码)、Software Cloning(软件克隆)、Software Propagation(软件繁殖)

最常见规模:应用层

重构方案名称:Black Box Reuse(黑盒复用)

重构方案类型:软件

根源:懒惰

不平衡的力量:资源管理、技术转移管理

轶事证据:“嘿,我以为你已经修复了那个错误,为什么它又这样做?”“伙计,你工作得真快。3周内完成40万行代码是了不起的进展!”

Mushroom Management(蘑菇管理)

在某些架构和管理圈子中,有明显的政策要把系统开发人员和最终用户隔离开。体会:隔离是主要的,联系也是必要的,关键是度的问题。