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

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

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 Foote 和Joseph Yoder 主持的一个议程。

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

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

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

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

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

正如Dave所说：

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

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