欢迎来到天天文库
浏览记录
ID:5281793
大小:258.96 KB
页数:2页
时间:2017-12-07
《1 软件维护的噩梦》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、软件维护的噩梦Mainz'sBlog我们很多时候可能不是那么幸运的被叫来做软件开发工作,而是做现有软件的维护。比如前人跳槽了,或是安排做其他工作去了,剩下的已交付的软件就需要人来继续维护。这可是一个苦差事,首先要看得懂前辈的代码,然后就是软件支持、改bug、改功能、加新功能,等等。反正就是做痛苦的修修补补的工作。比起软件开发来,软件维护简直就是无聊透了,首先不能出成绩,虽说维护庞大的代码不比开发来的容易,先前软件架构不好,维护性差,那你工作量就大了,可你做好了也就是个维护工作,没有创新,没功劳,如果有功劳,那也是前人栽树后人乘凉啊,前辈们系统设
2、计的好。其次是工作内容很枯燥,谁愿意费尽心机去看懂别人的代码呢?更何况有的代码是没有文档,没有注释,没有良好的命名规则的三无代码。即使有文档,文档基本很久没有更新了,和代码对不上号。看这种代码,改这种代码,简直就是对自己的耐心的一种折磨和考验。更加可怕是,尽管设计说明书上描述的架构设计的如何精巧灵活,结果事实往往不是这样,在新的功能需求面前不堪一击。很多时候改了一个小地方,结果会触动其他的隐藏的很多神经,任何修改你都要小心翼翼。除了原来的程序员,没有人确切的知道某某功能点需要修改几个地方,哪儿和哪儿是相互关联的,这个功能会影响那个功能。有的时候
3、甚至连需求功能点列表都没有留下。这简直就是软件维护的噩梦。最后的结果就是:“钱基本花光,人基本跳光,甲乙双方感情基本破裂。”其实从软件生命周期来讲,任何一个软件总有一天,它的架构会越来越不能满足新的需求,会走到尽头的时候。但不到万不得已,客户不会抛弃原来系统而花大价钱去开发一个新系统的。所以讨论如何进行软件维护还是有一定意义的。难道就没有维护性好的系统?我见到的一些老系统运行了几十年很稳定,维护的也很好,(可能刚上系统的一两年会比较痛苦吧,但从几十年来看很稳定)比如银行和电力的老系统,最后直到前几年银行大集中的时候才上了新系统。难道他们的系统那
4、么强悍吗?难道他们没有新需求出现吗?错了,其秘密在于银行核心的业务基本没变,所以软件的核心价值和功能没有变,变的只是些小的边缘的需求,银行会不断在上一些非核心的业务和系统,但前提是不修改不影响核心业务系统的运行。我想这一点对做软件开发和维护的人来说有点启示。如何把不经常变的东西挖掘出来?起初设计系统的时候,就应该集中在核心业务需求上,因为那才是这个软件的最大价值和核心。核心价值不能变。对这个核心业务价值的设计应该具有良好的扩展性、维护性、和稳定性。当然,全面细致的文档,及时更新,都是非常重要的,能抵御人员流失的风险。从维护重新认识软件生命周期•
5、软件维护通常占到软件总成本的40%-80%,维护可能是整个软件生命周期中最重要的阶段。•功能增强(Enhancements)可能占到60%的软件维护工作。•软件维护是一个解决方案(Solution),而不是一个问题(Problem)。•理解现有的软件是软件维护中最困难的工作。•复杂的逻辑、功能和配置都降低了软件的维护性。软件维护中的创新:重构被分配到做软件维护,其实也能够学到很多东西,也可以在维护中间思考如何进行重构。因为任何一个成功的软件都是不断进行重构才真正成功的,从1.0,到2.0,重构到3.0,甚至到8.0,任何时候都不要以为软件已经完
6、美,任何时候都可以进行重构。当软件千疮百孔,不堪重负,对新增需求举步维艰的时候,就是重构的时候了。但重构要注意两点:首先是重构要保持系统的核心价值不变。例如,老的软件的最大卖点是体积小,启动快;这个对用户的核心价值在以后的重构中不能丢,否则就会失去用户。其次是重构必须要注意风险。重构的前提是要对老系统非常了解,功能点、架构、实现细节、依赖关系、强项与弱项、相关文档、业务逻辑等,都要非常了解。另外一个重构的前提是有质量保证,单元测试、功能测试、回归测试,否则任何试图重构和解耦系统、试图提高代码结构、性能和维护性的努力都会带来极大的风险。
此文档下载收益归作者所有