大泥球的成长之路

前言

上周组织团队对一个遗留系统进行架构重构，发现了一个模块是典型的大泥球架构，极难重构，本文将回顾大泥球的形成的主要过程，以便大家尽量避免大泥球架构带来的伤害。

大泥球？

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

为什么不？

为什么大泥球的架构不好呢？下面是几个最为直接的因素：
1. 可维护性，什么会阻止你修复系统bug，大泥球架构是一个很好的理由，牵一发而动全身的感觉不是一般的酸爽。
2. 可靠性，如果软件的全部耦合在一起，牵一发而动全身那么其面对异常情况是是很难做到高可靠的。
3. 可修改性，对于软件来说唯一不会变化的事情就是变化本身，因此软件的修改或调整是不可避免的，大泥球架构会令你望而却步。
4. 可继承性，软件不可能由同一个软件团队一直维护下去，人员的更替是不可避免的，大泥球架构往往意味着人员掌握着软件真实的设计，新团队接手后往往选择重新开发。

大泥球的是如何滚动的？

说起我们的这个大泥球项目可是有历史了，项目在13年就开始了，在14年底上线，经过近三年的更新维护，在不知不觉中就滚成了一个让人叹为观止的大泥球。
项目分为两个阶段:

开发阶段

作为一个典型的政府主导的新型行业性项目，在需求没有一片模糊的情况下，直接上马也是斯通见惯了。
由于缺乏有效输入，也没有专人负责，用户方只有高级领导的情况下，我们采用了原型设计的方式启动了项目，通过mockup构建示意性界面梳理业务模式，在通过Axure制作高保真的界面确认需求，经过长达半年的需求分析和讨论，我们又用了三个月构建出了系统的第一个版本，又经过几轮讨论和三个月的时间，系统顺利验收和开始试运行，这时一切都美的如同神话。我们高效，深得用户欢心。

维护阶段

项目开始试运行就不是那么顺利的了，由于前期在需求分析时完全不知道还有一帮实际使用系统的丙方的存在，在推广会上被一通喷，直接用户也是立即变了脸色要求系统快速更新以适应业务需求。没办法这个锅确实应该背，做了近半年的需求分析竟然没有彻底摸清干系人，也是醉了。
于是大泥球开始滚动起来了，根据用户的强烈反应，我们制定了高强度快节奏的开发计划，每周进行迭代，每周进行系统更新和收集用户反馈。
就这样每周都有新的业务需求变更涌入开发功能列表，每天都有新的开发任务，在高强度的业务压力下，其他的一切都不那么重要了。
于是下面的现象开始出现：
- B模块出现了A模块类似的业务需求，时间那么紧顾不了那么多了，直接把代码copy过来改一下就ok了；
- 什么单元测试？哪有时间搞那玩意，明天系统就要更新了，我这还有一个功能点没实现呢，最后人工测一下好了。
- 什么C模块也要实现空间统计分析功能，什么明天有领导要看，好吧，那我就直接把A的代码直接复制到C这好了，数据结构也跟A保持一致就好了。
- 这段代码这么写好像有问题，加个注释吧，以后再来解决。

时间的力量是惊人的，直接到一个月之前我发现代码重复度至少达到了20%，能把整个系统结构说清楚的人不超过1个，对系统了解超过50%的人不超过2个，系统要依赖源码来运行因为tomcat总是因为不知名的原因挂掉。

好在上天还是眷顾我们的，这个系统表面上还是正常。

原因回顾

• 需求碎片式增长
• 只关心是否能够运行
• 高强度的业务压力

导致结果：

• 没有精力关心质量
• Copy/paste导致问题转移（有问题的代码被复制到很多地方，不断蔓延）
• 我们不知道现状到底有多糟糕
• 应对架构变化过晚

总结

除非你能确定你的软件不会有任何修改或任何人使用，那么大泥球的软件是可以接受的。

最后的总结


 - 别把计划排的太满
 - 防止温水煮青蛙，任何大泥球都是经过长时间的滚动形成的，没人想设计一个大泥球架构的软件。
 - 设置代码质量监控，不要留破窗户
 - 保持代码整洁，离开时要比进入时干净