痛苦的系统，艰难的维护
http://www.cnblogs.com/lane_cn/archive/2006/06/09/421175.html

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

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

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



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



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

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

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

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

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

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

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

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


posted on 2006-06-09 00:36 小陆 阅读(1489) 评论(40) 编辑 收藏 收藏至365Key 所属分类: 软件工程实践


评论
# re: 痛苦的系统，艰难的维护 2006-06-09 00:48 畅想自由
有点意思。好象生活就是这样的。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 02:35 Henry Liang
怎么好像是在说我？呵呵~~~
有的时候，在设计过程中我提出了一个建议，头儿在思索了半天之后说：“你的想法很好，但是先按这样的思路做吧。”
“以后？以后就晚了……”这句话我还是终于没有能够说出口。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 07:42 办公平台
我相信在国内大部分公司都是这样的 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:04 悟
说来说去是一个抽象层次的问题，层次分得越多越合理，设计和开发的难度越高，维护量相反；这年头连大企业的大多数开发人员都是想能交差就行，管它呢，说不定明天我就走了；维护关我什么事。这样的恶性循环跟那些头头不懂技术有关。
简单说，很少人会关注后续维护成本，只在意当前的开发成本和所谓的交货日期；说实在的，很多东西早1个月和晚1个月根本就是一样......

能交差就有钱，不能交差，设计再好的东西也没有用；忘记是哪人说的。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:26 追求卓越
@Henry Liang
差不多。经常是为了以后考虑的预留的功能，头们认为没用，等到用到了，就要你加。这时候程序已经被头们的要求改的面目全非了。
有的时候需要头们作出决定，他也拿不定主意，自己做决定，又说没和领导商量。不论做成什么样子，都说做的很丑，真TM烦。有的时候绕来绕去，又回到最初自己提出的方案上来了。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:33 81
说实在的，很多东西早1个月和晚1个月根本就是一样......
===============================
确实这样，前面已经花费了半年讨论上不上系统，领导最后一句话：一定要上，下个月1号系统要正式运行。

然后我们就开始乱写程序了，一边还在给客户的小领导说，如果多给一个月，我会做的更好。小领导却说，虽然我也知道，但下月1号如果不上线，我没法向上级交待！
回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:42 昊子
开发人员总要坚持些什么，做不好的不做，没决定的不做，
领导不懂技术技术人员就应该发挥作用给他们讲解，而不是背后看笑话。

仔细想想这里说的话跟你的头沟通过么，还是只是臆测头头们不会听你给他讲解你的设计。

//也许大家都在期待一个改变的机会。
每个人都梦想成为英雄，却又在关键时刻希望出现英雄 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:45 萧远山
@悟
同意你的观点,如果能在整体业务上再做好业务抽象,统一接口,对于流程方面,如果不用工作流引擎,也要用上一些可配置的参数来控制流程,这样修改的工作量就少多了....
这个项目各个方面都有问题,从项目的管理,需求分析,系统设计等,还是要从源头上找问题... 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 08:57 lovebanyi
我现在都不在坚持了...多少时间交差就做多少时间的事情 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:03 Cure
前面已经花费了半年讨论上不上系统，领导最后一句话：一定要上，下个月1号系统要正式运行。
-------------------------------------------
有意思 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:04 契约
合乎现在很多公司的特点。。。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:05 henry
这种系统很麻烦,很多原因是数据来源不确定性.
很多地势局是不太愿意修改他们的数据来适应你的系统,往往是反过来修改系统来适应他们.随着系统使用范围扩大,产生的问题就会越多. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:07 梁广永
个人感觉
LZ对分析设计的部分过于一笔带过（尽管不可能太详细）。
没有说清问题 ，
就直接定性,下结论。
给人不明白！ 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:22 胖子
不按领导想法做的，做的再好也是不好。
按照领导想法做的，做的再烂也是好的。

这让我们哪里有技术创新的动力？最多也就是在某个方法的具体实现时用点儿小技巧吧 ：（ 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:26 有癖者
一级棒！思路清晰，分析透彻，整个流程看似简单却又有着恼人的错综复杂，工作应该就是这样，有这样的痛苦和艰难才能构成生活的多姿多彩 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:28 henry
现在你站在问题当中,所以认为之前的设计不合理.但有很多所谓的问题在刚开始是不存在的,设计时要达到适应任何变更是不可能的.
当出现问题又不去调整重构代码是导致系统越来越多问题的原因之一(有那几个PM会允许你这样做?).一个比较关键的问题就是能否够控制好变更,业务人员说改你还可以反驳他,如果领导或老板说呢?客观因素太多了,设计只能解决一部分问题. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 09:46 川仔
非常有意思。。。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 10:23 追求卓越
@昊子
我们不是没有沟通，沟通的结果还是按照领导的意思办。
现在真佩服头们，口才那么好。。。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 10:32 不老仙翁
看得出来，架构设计师还是会有市场的。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 10:50 tototo
等你从技术的角度跳出来，你就发现以上的问题都不是问题了，至少不会那么辛苦了。

回复

# re: 痛苦的系统，艰难的维护 2006-06-09 10:51 vejson
中国大多数软件企业都这样，关键缺少好的架构设计师，中国很多软件企业没有架构设计的概念。只有项目经理兼职业务分析。。。。。。。。。唉。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 11:01 smalldust
很显然，你们的项目缺少架构师和合格的系统工程师，导致先天不足，后天瘫痪。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 11:10 DotNet菜园
设计有缺陷，业务不完整，大家都很困惑，难道什么东西都要提出书面需求才能去做吗；

如果你不按书面需求来做,能及时完成并且得到用户认可,那什么问题也没有.
你还可能得到加奖.
如果没得到用户认可,那么后果 ............. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 11:19 不老仙翁
不客气的说，项目经理的老师水平在80年代未，项目经理本人也是只会用“只用合适的，不用先进的”之类的理论来掩盖自己在技术及管理上的无能。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 11:19 mendole
对小陆的描述，我深有体会，经过认真地思考我做了些改变现状的努力，在这里贴出一段我某个项目的小结的一段话，希望能给大家一些新的视角，当然也希望大家批评指正不合理的观点。

项目计划中的陈述：

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


项目总结中的陈述：

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

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

# re: 痛苦的系统，艰难的维护 2006-06-09 12:29 Bear.sTaR{R}
我们公司的项目开发和楼主的情况差不多，郁闷了N久。

一个项目2个月开发完了，维护到现在差不多半年了，还是没完全结束。

难道中国的大部分软件公司都这样吗？？？ 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 12:34 Bear.sTaR{R}
差不多。经常是为了以后考虑的预留的功能，头们认为没用，等到用到了，就要你加。这时候程序已经被头们的要求改的面目全非了。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
强烈同意，前天和老大去客户哪里收集需求，项目准备分2个阶段开发。
让我惊讶的是：老大跟客户说因为项目分2阶段，所以今天只收集第1阶段的需求，然后我们去开发。开发好了后再来收集第2次需求，再开发第2阶段。

我就想，第1阶段开发如果不考虑第2阶段的需求，不为以后留下些接口和扩充的能力。估计第2阶段开发要把第1阶段的改的乱七八糟的。但人家是老大，没办法，只能是郁闷。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 12:39 ro4tub
敏捷开发,正是解决这类问题的过程.但是要坚持这个过程(agile开发)也是很难的. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 12:48 铱星
现在的小公司似乎都是这样，只能一个词来形容--混乱
做到后来，每个人都疲惫不堪 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 13:12 neoragex2002
你们这经理有意思，呵呵，带着股子闹革命的匪气来做无谓的煽情 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 13:29 蛙蛙池塘
有时候是有心杀敌，无力回天呀，个人技术再高也不行，每天累的不行，到头来做的东西其实你自己就感觉很垃圾，敏捷开发确实能缓解一些这种现象，但有时候还是没时间去对代码复查、重构，都是逮哪儿打哪儿，一个补丁一个补丁的往上摞，现在搞的上班下班脑子里都是放不下的代码，脑子跟炸了似的，不是攒害怕变化，没有勇气推倒重来，实在是太琐碎，太麻烦了，不过还得端正态度，该咋办咋办，不要有怠工情绪就好。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 14:53 81
这就是中国特色的软件业，每次看国外的经典软件书籍，说怎样怎样，感觉中国内是不可能的。 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 16:06 极地银狐.NET
楼主说的就是传说中的"熊",要有"银弹"才行.中国真的有么?我不知道,记的去年JAVA那边在推面向构件的开发,不知道怎么样了. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 16:34 丁丁
大家太忙了，忙得连思考的时间都没有了 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 16:47 Royh
重构重构重构。

不知道头是否允许今天什么新功能也没做出来，只是整理了一下原来的代码。
回复

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

无语

大家好像都差不多

所以 真的 怎么简单 就怎么来吧

唉

架构 思路 流程

回复

# re: 痛苦的系统，艰难的维护 2006-06-09 18:44 维生素C.NET
权利太过集中了. 回复

# re: 痛苦的系统，艰难的维护 2006-06-09 19:53 RickyLin
我们这里也是这样，我做过的一个系统，还不明白需求是怎么回事，就要求一个周做出来，并运行，还是在五一期间，干了个通宵，系统跑起来了，后续问题至少解决了1年多……
后来又遇到一个一样要求的系统，本来应该长经验了吧，嘿，老大还是真要1个州弄出来，
我无语，辞职中…… 回复

# re: 痛苦的系统，艰难的维护 2006-06-10 13:44 fifa
和我的软件差不多啊，比较烦。以后谁想来我公司做架构师，说一声啊。 回复

# re: 痛苦的系统，艰难的维护 2006-06-12 15:43 有什么问题吗?
需求分析很重要，在整个设计周期中应该占有相当比重。
这是个功利的时代，业务部门恨不得今天需求提了明天问题就可以解决，系统如何实现需求与他们无关，系统实现不了他们又找到了一个业务没发展好的理由。急用先行，这是我们耳熟能详的一个词，系统的负责人有几个能顶住这样的压力，按自已的想法做出一个好系统呢？ 回复