痛苦的系统，艰难的维护

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

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

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



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



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

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

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

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

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

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

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

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



在这里贴出一段我某个项目的小结的一段话，希望能给大家一些新的视角，当然也希望大家批评指正不合理的观点。

项目计划中的陈述：

需求阶段还要根据需求完成所有页面以及页面元素的定义工作。
详细设计阶段还要根据各类需求完成整体框架和业务逻辑层接口的定义工作，并用Mock（替身）原理【参见单元测试】，简单实现所有业务逻辑层的接口（比如：对返回的数据硬编码），并用此简单实现完成UI层的开发、调试和测试工作【主要是让最终用户体验产品功能】，通过这种方式发现、完善和测试需求的正确性和BLL层设计的正确性。


项目总结中的陈述：

在xxx项目中，对经典的软件生命周期做了些改变，将UI表现层提前到需求分析阶段开始，到设计阶段完成，与业务逻辑以及数据访问层分离开来，在不同的阶段实现。与传统软件生命周期相比有以下区别：
首先，提高了工作效率。在传统的软件生命周期的需求分析阶段一般要作些效果图，但非正式的界面，到编码阶段按效果图开始做UI及UI与业务逻辑层的衔接，而xxx项目在需求分析阶段就开始建立正式的开发环境，做正规的界面设计【具体到所有功能页面】，到设计阶段应用Mock技术，实现接口设计和UI层与业务逻辑层的衔接，到编码阶段只需完成业务逻辑层和数据层的开发；
其次，增加了需求分析的力度。由于在设计阶段就可以完成UI的开发工作，一方面可以借助Mock技术，从用户体念方面基本可以感受最终产品的绝大部分特性，用户可以根据这样一个有型的初级产品发掘较深层次的需求；
另外，降低了项目后期的项目风险及因需求变更带来的项目成本。

由于，本项目是首次引入此概念，应用起来还不是很熟练，还有项目进度要求较高，实施项目生命周期的改造取得了初步成效，但还需要在后续的项目中注意实践和改进。