项目管理之老系统维护.docx

项目管理之老系统维护.docx

《项目管理之老系统维护.docx》由会员分享，可在线阅读，更多相关《项目管理之老系统维护.docx（10页珍藏版）》请在冰豆网上搜索。

项目管理之老系统维护

今天收到了老板给的一篇关于老系统维护的文章,本人读后有了,了解了很多,也清理了本人诸多的模糊想法,现将此文章分享给各位,原文如下:

我之所以把这个主题放在过程管理篇的第一部分,就是因为很多程序员每天干的工作,不是在开发新系统,而是在维护老系统。

这个理儿大家都清楚,世界上哪有那么多新项目新产品开发啊。

一个公司,也就是那么2~3个产品,也不可能老有新的产品出现。

那么多程序员,只能做维护的事情了,不断让软件升级,而这个软件是谁写的第一版代码,都无从查起了。

一翻开源代码,会看见各个时期各种风格的源代码,甚至很多源代码都没有注释,根本不知道某些代码干嘛要那样写,到底是为了什么目的。

一天早上,有个网友给我发了一条消息:

他是一个老产品版本维护开发人员。

他应聘到这家公司的时候,这个产品已经卖了4年了。

最初的开发者已经都在这4年中不断流失走掉了。

他来了,任务就是维护这套软件,而且就他一个人维护这套台面,有BUG改BUG,有需求改需求。

虽说这套软件卖了4年,但真不知道是怎么坚持了4年。

他接手的时候仍然是BUG百出。

代码没有文档,没有注释,连表结构说明都没有。

代码莫名其妙,经常横插一句代码。

显然是客户报告了某个错误,为了临时决定这个错误而做的针对性处理,但到底是为了修补什么错误,代码也没有说明。

所以他不敢乱动,但还要需求,只能硬着头皮来。

他也不知道自己修改的代码是否还会引起其他的问题,只能凭空企求千万不要出问题。

老板还在到处吹产品很成熟,而他每天都在心惊胆战,害怕这套代码不知道哪天突然崩溃,出了错误自己都收拾不了,那只能自己被K掉。

他能想象得出老板发怒的情景:

这么稳定的产品你都搞不定?

!

他希望我能帮他出出点子。

我想了想,能有机会开发新产品或新项目的程序员是很幸运的,因为没有历史包袱,白纸画画。

而现在大部分的软件公司都是拿一套已经有了型的代码到处修改,客户化为新项目。

真正做一个新项目,从头编写这个项目的第一行代码,这样的机会比较少。

对于修改现有代理适应新客户新项目,这种情况非常多,也是大部分没有文档,修改定制没有注释。

客户打电话说一个需求,技术能达到就答应下来修改,修改完就给客户覆盖,根本没有需求管理、版本管理。

而这样的代码,还不是一个特定客户一套特定定制化代码,是要给其他客户也更新的。

很可能这个客户好使,那个客户使用其他功能的时候就出错。

按下葫芦起了瓢,是很常见的现象。

我问他:

“现在你改的代码有注释吗?

”

他回答:

“没有,自己修改的自己都记得,即使忘了,看看自己写的代码也能回忆起来,所以也没有写。

”

我问他:

“那以后你走了,其他人怎么办?

”

他回答:

“反正也是一个烂产品,其他人怎么办,他就管不了了,就应该让这套烂代码尽快死亡,省的祸

害别人。

”

我问他:

“那你找我帮助的目的是什么?

”

他回答:

“在我工作的这段期间内,它不要崩溃就可以了。

”

我无语了。

关于老系统维护这个话题,我喝许多开发人员都有过深入的交流探讨。

许多从事开发的网友认为,一个老系统要维护好,必须具备以下关键因素:

有责任心,有文档,设计前做好详细的需求分析,要有需求管理,要OO编程,要有专门的测试人员。

如果没有这些,干脆推到重来,如果不让推到重来,那就赶快跑路,否则就容易当了冤枉替死鬼。

但现实中,往往维护老系统的就一个人。

这是很矛盾的事情。

一个软件的开发,往往1~2个月就完成,而

它的销售、实施、升级周期却长达4~8年。

但每个老板好像都认为软件已经开发完毕,修补修补都是小功能,所以一个老系统维护人员就OK了。

殊不知白纸好画画,而要在别人的画儿上再能点睛成龙就是难上加难了。

我在管理运营企业的时候,发现遇到的难题也和维护老系统面临的很类似。

都是缺这缺那,部门之间利益

冲突,人的素质怎么也提不上来,员工和老板互相做猫和老鼠的游戏,不断博弈薪水和付出劳动力平衡。

总有些公司的历史---留下的人留下的势力格局留下的客户印象留下的做事方法不能改变,也无法推翻重来,但公司还要发展还要提高,就必须已目标为中心,不断像骆驼一样挺着风沙干渴饥饿领队前进,有各种困

难阻碍都要不断清除,无法根除就想办法平衡与缓解,时而让步时而迂回时而强势时而突然决策突然执行,公司就这样不断持续经营下去。

所以,维护老系统,也要想经营企业一样,不断继承包袱,不断细心剖析问题,剥茧抽丝理清思路,不断

改进,不断渐渐从恶性循环走向良性循环,才能把一套烂代码扭转成可持续维护的代码。

写代码的8项建议

1、重点把控输入数据的校验。

你看见很多横插进来的代码,就是由输入的漏洞进入,最后引起后续数据处理出错,所以以前的程序员不截源头,在最后爆发的地方堵漏洞。

现在Windows程序都是消息事件触发式的,还说不准这个流程会走到哪里,他堵的了这个口,其余他根本想不到的触发,能堵住吗?

所以,把控输入数据的校验,在保存按钮第一步代码中写好集中的详细校验。

而且,这块代码要写成函数,不要大流水,省得代码复杂性会让程序加速崩溃。

2、以后的需求再往上加,都写成函数。

遇到比较大的IF..else判断,就从其中的代码段再分出一个函数。

3、以后再加功能,尽量不要做成联动触发的。

也就是说,保存,最好是单表保存。

即使是主从结构的单据,如果客户不强烈反对,也先保存主表后再让录入明细表。

而且录入明细表要单独的窗口,这样功能和代码都简化了。

如查询一张单据,也不要上边是主摘要,下面就是明细联动。

这样会影响性能。

更因为速度可能慢,用户会连续点击多次,触发事件就会乱,莫名其妙错误就都产生了。

最好是双击主摘要,弹出独立的窗口显示明细。

4、以后写代码,分离特殊处理业务和正常处理业务的功能代码。

就好像你走路,老有人给你下绊子,你就感觉不爽。

5、对不常用的功能做一些隐藏处理,将其放到一个不起眼的位置。

使用的人就会越来越少。

到时候就适机真正隐藏掉,不让它触发了。

6、写代码时,避免全局变量和大流水代码。

其实很多时候,你觉得程序很烂,索性破罐子破摔,是由于以前程序员的代码排版可能和你不一样。

你喜欢两个空格,人家喜欢三个空格,你就觉得不爽。

人家喜欢把{放在最后,你喜欢新开一行。

你可以使用代码格式转化工具重新排一次版。

我看到很多老代码维护人员,抱怨变量都是M、N、S、Button1之类,但其实你阅读理解代码,这些并不会使你理解有歧义或不懂,只不过你不爽而已。

理解了这个不爽,你就会心平气和一些,修改代码会更加顺利一些,你越和旧代码生气,你的工作越乱。

看到这里,相信很多程序员都会会心一笑。

真正的根源在此,老系统无法维护只是借口而已,可能是希望老板认为自己的工作很辛苦很复杂而加薪!

真正危害大的是全局变量和大流水代码。

所以写代码,要严格避免这两个坏因素。

7、修改需求或BUG的时候,要按照模块来源集中修改,而不要挑好改的先改了,不好改的就最后改。

按照模块来集中修改,你会通盘考虑所有这些需求和BUG,而不是糊窗户式的补漏洞。

8、多写视图,多写存储过程。

我曾今和很多做维护的开发人员都做过交流。

他们都觉得一个软件没有文档,没有注释,简直就没法维护。

但确实是很多软件没有任何设计文档,连帮助说明都没有,代码也没有

注释。

而这些软件又出自他们自己之手。

也就是说,他们一边抱怨没有文档没有注释,一边自己也不做文档不写代码注释,不知道在等谁来专门做。

我问他们到底需要什么文档才可以将一个软件维护得越来越好,从一套烂代码扭转到一套良好渐进的代码?

他们说要表结构说明,要详细功能设计书。

表结构还好说,可以整理出来,详细设计说明书就不容易出了。

我曾今也维护过别人的代码,也是什么文档都没有,连操作使用帮助都没有,更别提详细设计说明书和表结构,代码当然没有什么注释。

我并没有去整理表结构说明。

幸亏这个人喜欢在数据库上倒弄,写了大量的视图和存储过程。

视图中有各个表之间的关系连接,也有各个表中重要字段的中文含义。

这样我就不需要表结构说明了。

因为表结构说明不仅需要描述每个表中字段的中文含义,也得描述表之间的关系,这和视图能表达的效果是一样的。

所以,我现在也建议开发人员写代码,多写视图,多写存储过程。

有的老代码,SQL语句都在代码中执行,没有视图。

对于这样的老系统维护,就是把这些SQLCOPY出来,做成视图,这样就好维护了。

至于详细功能设计书,其实对于程序员来说,其目的是想弄清楚业务流程的来龙去脉细节。

光直接看代码很难弄明白意思的,又没有什么其他文档可以参考,所以只能猜测代码的意思。

尤其很多维护人员,很多功能细节都是为了处理某些特殊需求和异常业务的,都是以前程序员写的,但是以前的程序员已经走了,现有的维护人员连软件中具体的细节功能是怎么回事,程序员都发蒙,嗯,还有这个功能?

我也不知道呀。

要解决这个问题,我曾今做过的事情就是组织实施人员写功能操作说明帮助。

因为实施人员要给客户去培训讲解,没有帮助说明,只能一张嘴“叭叭叭”地干说,实施人员是最需要功能操作说明帮助的。

但是实施人员认为这个帮助是软件的一部分,而且是开发部开发的软件,开发部最了解功能,所以帮助文档应该开发部写。

而开发部认为开发部的职责就是编写代码,你自己培训连个操纵说明都没有,你怎么培训,所以帮助文档应该实施部门自己编写。

于是帮助文档谁也不写。

归根到底,帮助说明是终究要写的,主要是谁写的问题。

谁最有动力写呢?

实施人员最有动力,因为这和他们的工作息息相关,而程序员明显没有动力理由。

而且实施人员熟悉第一线客户的素质,理解客户的具体操作思路和理解思路,写出来的帮助客户都能理解,帮助文件才能真正为客户服务。

很多帮助文档的写作都是由从来没有见过客户没有实施培训过没有给客户支持服务过,连软件测试都没有做过的纯粹文档人员编写的,可想而知帮助文档到底能对客户有多大的帮助性。

在写帮助说明的时候,我要求实施人员把每个按钮都要点到,每个GRID中的每一个字段数据来源和数据含义,每一张报表中的字段的数据来源和数据含义,每一个明细录入中的字段数据来源、数据录入要求和数据含义都要说明到。

这一写不要紧,发现了很多隐藏的特殊处理功能。

很多功能很多人不了解,因为很多细节功能,都是为摸个客户定制的,只有负责实施改客户的实施人员才知道。

于是,实施人员之间互相通

气,才算补足了不少功能细节的帮助说明。

实在有写功能,都不知道是哪家客户提出来的需求,也不知道为什么要这样处理,就留下空白,转给开发人员,让开发人员看看代码是怎么处理的。

就这样,一份详细的帮助说明在压力艰难中终于出来了。

从此,开发人员理解需求快了许多,当然也就明白了那些在过去自认为乱七八糟的代码的含义,心情好了很多,修改代码也轻松了许多。

原来,一切都是自己跟自己跟自己作怪。

不盼望软件工程,不抱怨一穷二白,不幻想加人手,从现实入手解决自己的问题,发现很多解决方案既简单又有效,根本无需动辄就是团队就是UML就是OO。

另外,需求也是维护人员很头疼的事情。

我的手下也经常问我:

客户必须让咱们接他们的需求改,您看怎么办?

客户需求!

客户需求!

客户需求,这个让开发部最头疼的字眼!

每当想起客户需求,就想起了一下这些话:

1、程序员说:

这是你们家个性的需求,太邪门,我们不做。

客户说:

不做我们找你们老板去,我们是花钱买了你们的产品的。

2、客户说:

我们不会用鼠标,你给我做一个语音输入吧。

我们还想要一个类似QQ的东西供我们内部沟通,你们给我们做一个吧。

程序员:

我晕!

3、程序员说:

等你们内部斗争完,你们协调完了,我再调研需求。

似乎,我们在需求上无能为力,我们永远在追赶客户的需求,满足他们的现状,把N多家的客户需求都加进软件中,只要能实现的,我们尽量咬牙实现了。

最后,我们发现,我们的软件无比复杂,谁也不会用了,连开发部门都不会用了,谁也不知道这个需求当时为什么要这样做。

因为无比复杂,所以实施、培训、技术支持都成了问题,稳定性更成了问题。

代码互相交叉,根本无法理清有多少交叉影响点。

维护的程序员都快崩溃了,天天在