痛苦的系统，艰难的维护

一个7×24的帐务系统，一个每天都要开门营业的营业厅，运行了好几年了，小改小闹几乎天天不断，大的升级隔半年到一年就要有一次。外界还有新的系统要接在上面，不断的开拓新的接口，功能不断扩充……

系统最近一次大的升级，就在今年的3月。当时开发公司来了几十个人，平时人烟稀少的机房里面挤满了人。升级前一天的晚上，项目经理召集广大人民群众，发表升级前的最后一次讲话：“大家忙了n个月，就是为了这一天。再给我顶住，到明天这一切结束的时候，胜利将属于我们！”我站在边上，对我的同事说：“到明天，当新的系统开始运行的时候，一切只能说刚刚开始。”

就像我以前见过的很多系统一样，这个系统开发的最初阶段先搞数据库的设计，数据库的设计就像下面这个图，一个一个的数据表，一对一的，一对多的，多对多的关系：



数据库设计的时候，需要用各种业务流程对数据库的设计进行验证，这两个设计是同时进行的。当数据库差不多设计完的时候，业务流程也应该明白的差不多了。业务A执行的时候增删查改这些数据表，业务B执行的时候增删查改那些数据表，系统的设计就这样渐渐形成了。



就这样，n个业务流程在数据库表的丛林中穿行，像迷宫一样，所过之处数据发生变化。一番抽丝剥茧，详细设计完成。然后大家分配工作，照着设计书写代码。忽然有人发现设计的问题，重要人物召开会议了解情况，商量对策。对策通常是数据库要加上几个表，几个字段，某几个流程再拐几个弯。大家改改代码，继续埋头工作。

然后测试，然后补充各种文档，这时候时间越来越紧张，也许已经延期了好几次。终于，可以部署到现场运行调试了。按照开发商的说法，一切都结束了。

对于开发商来说，一切都结束了，但是对于用户来说，一切才刚刚开始。维护一个这样的系统，是一件痛苦的事情。

系统有Bug，总是改不完；
设计有缺陷，业务不完整，大家都很困惑，难道什么东西都要提出书面需求才能去做吗；
新需求不好做，业务流程的迷宫太复杂，无法避免对现有需求造成影响；
功能扩充了，数据增加了，业务扩展了，效率也下降了，买CPU吧，加上去试试。

系统就这样维护，没办法，这就是工作。

和一个开发人员谈过这个系统为什么要做成现在这个样子，他的说法是：这样做的理由有两个：

1、这样的设计层次少，业务实现很直接，效率高。（这个原因没人相信，包括他自己）
2、一开始就是做成了这样，后来的项目时间紧，任务重，直接拿着前人创造的成果改一改，就可以交差了。（这是个很合理的理由）

也许大家都在期待一个改变的机会。