"大泥球"仍然是最常见的软件设计

  • Vikas Hazrati
  • 郑柯

2010 年 9 月 17 日

话题:敏捷架构文化 & 方法

大泥球,是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来,为了对付这个泥球,我们看到了多种指导方法,比如SOLIDGRASPKISS,与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而,实际情形没多大变化,“大泥球”看起来仍然是设计软件架构的最常见方法。

Dave Nicolette最近提到他最近看到下面这样一段 Java 代码

public Thing getThing(Integer id) {

    return new Beta().getGamma().getDelta().getEpsilon().getOmega().getThing(id);

}

这段代码有很多“味道”,比如:

  • 消息链:要得到结果的调用有六层之深。
  • 不当的亲密关系:客户必须知道其他类的内部结构才能得到结果。
  • 不当的暴露:beta、gamma、delta 等等方法允许了不当的暴露关系,才能得到第三个对象 。

在 Dave 看来

尽管关于该主题已经有非常丰富的信息,看起来开发软件谋生的大多数人要么

(a) 对于任何优秀软件设计的指南完全没有概念,或者

(b) 对指南理解存在严重问题

FJ 也同样回忆起了 Agile 2009 大会中由Brian FooteJoseph Yoder主持的一个议程。

大泥球发生的主要原因可以归结为:

  • 一次性代码
  • 碎片式增长
  • 为了让软件不出问题
  • Copy/paste 导致问题转移(有问题的代码被复制到很多地方,不断蔓延)

有趣的是,根据 FJ 的记录,Yoder 认为 Agile 的很多方面会直接导致泥球,包括:

  • 缺少前期设计
  • 应对需求变化过晚
  • 应对架构变化过晚
  • 碎片式增长

Yoder 认为:敏捷之所以能起作用,不是因为其流程,而是因为很多实践能够让人们持续关注技术的卓越性、回顾、面对面沟通和得到激励的个体。Yoder 推荐的工具之一是:当软件质量下降时,采取简单的重构和测试。因此,看起来并不是流程能够帮助减少泥球,最终还是有责任心的程序员愿意承担责任、保持警惕。除非如此,不管是敏捷还是非敏捷,大泥球总会挥之不去。

正如 Dave 所说:

尽管涌现出各种鼓励、促进良好结构代码的开发方法,软件技艺运动也在不断成长,但是“大泥球”仍然是最常见的软件设计,即使人们已经从过去恶劣的设计中学到了东西,但在新的开发过程中,大泥球仍未消失。

查看英文原文: Big Ball of Mud, Still the Most Popular Software Design

敏捷架构文化 & 方法