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

作者 Vikas Hazrati 译者 郑柯 发布于 2010年9月17日

领域

过程 & 实践,

架构 & 设计

主题

质量交付 ,

质量 ,

软件工匠 ,

架构 ,

敏捷

分享到

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

译者 郑柯 InfoQ中文站总编。做过开发，当过PM，干过销售，搞过市场，最终还是回到媒体。实用的理想主义者，相信：每天改变一点点，这个世界会更好。

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

1. 返回顶部

   Refactor

   发表人 Wang Evan

   不重构，设计再好代码也会越来越混乱

   回复

2. 返回顶部

   Re: Refactor

   发表人 Ma Karl

   开发人员的自身素质也是很重要的。

   回复

3. 返回顶部

   老板想要什么

   发表人 Chen Steven

   这些都不是主要的，主要的是最快迎合老板的口味，或者说 老板的口味==大泥球

   回复

4. 返回顶部

   Re: 老板想要什么

   发表人 liu jun

   应该是客户===大泥球，工期太短，而且客户需求总是在变

   回复

5. 返回顶部

   这就是国情

   发表人 Liu Yulong

   国内软件开发普遍存在的问题，说到底是一种管理和制度的问题，在这个浮躁和官僚的社会里，必然会是这种结果。

   回复

6. 返回顶部

   国内软件行业反省

   发表人 guo jingwei

   反省自身的价值，尊重自己的劳动，更多的沉淀与积累。

   回复

7. 返回顶部

   说到底

   发表人 Tseng Joseph

   不完全竞争的市场是忽视质量的文化的根本原因。

   回复

8. 返回顶部

   Re: 老板想要什么

   发表人 yuhui Hu

   如果团队足够经验的话， 敏捷的本意不是“拥抱变化”么？

   回复