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

大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如 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