1,265
社区成员
发帖
与我相关
我的任务
分享软件维护到底面临什么问题？
虽然大家都承认“软件维护”是软件生命周期中的一个重要部分，可是一提起“软件维护”这个无奈的话题，很多人都恨不得逃得远远的。软件规模、软件质量、需求变化，无数的问题使得软件维护困难重重。
那么，软件维护到底有一些什么困难呢？我想到了这样一些问题：
1、软件难以看懂
1）原来的软件代码的书写习惯非常差，很难阅读，例如使用无规律的变量名称、过长的函数等；而且反复的修改使软件结构混乱，层层嵌套的注释更是难以匹配；
2）没有可以参考的文档，或者文档不全，或者文档太老；
3）现在的维护人员都不知道系统原有的业务逻辑；
......
2、修改带来不良影响
1）对某一功能模块的修改，需要做多大范围的测试才能保证它没有给其他模块带来负作用呢？
2）由于各种成本的限制，很多时候只能以“打补丁”的方式来进行修改，而不是全面解决问题，以至于积累了很多潜伏的风险；
3）跟踪软件版本的演化是一件非常困难的事；
4）对程序的修改，导致了文档的不一致；
......
3、原来的软件质量有缺陷
1）软件本身就有质量问题，只是日常维护已经很不容易，更不要说修改；
2）软件设计时为维护工作考虑得太少，例如对错误给出的提示很不清楚，过分依赖输入数据的正确性；
3）软件的可移植性、可扩展性很差。设备、软件（主要是系统软件）的更新换代对软件的兼容性提出了巨大的考验。可是，有几个软件在设计时充分考虑了可移植性呢？将一套系统从32位机上移到64位机上，即使没有对任何语句进行修改，也必须做全面的测试以保证不会突然当机；
4）软件的易用性不高，必须要专业人员才能维护；
......
4、客户需求不断变化
1）软件更新的速度赶不上需求变化的速度；
2）原来的技术、模式、结构不能满足新的需求；
3）多次变化后连客户也不清楚到底要什么；
4）层层堆叠的补丁给系统带来了预料之外的负担。例如不断增加的、过多的报表降低了系统效率。
......
5、软件开发人员的情绪
1）优秀的程序员都不愿意做系统维护这种枯燥的工作；
2）做系统维护占用的时间可能远远大于做软件开发，但薪水却不是保持同样的比例；
......
那么还有哪些问题是你在软件维护过程中经常碰到的呢？
欢迎大家贡献自己的力量，给我一些参考和建议。
那么，软件维护到底有一些什么困难呢？我想到了这样一些问题：
1、软件难以看懂
1）原来的软件代码的书写习惯非常差，很难阅读，例如使用无规律的变量名称、过长的函数等；而且反复的修改使软件结构混乱，层层嵌套的注释更是难以匹配；
2）没有可以参考的文档，或者文档不全，或者文档太老；
3）现在的维护人员都不知道系统原有的业务逻辑；
......
2、修改带来不良影响
1）对某一功能模块的修改，需要做多大范围的测试才能保证它没有给其他模块带来负作用呢？
2）由于各种成本的限制，很多时候只能以“打补丁”的方式来进行修改，而不是全面解决问题，以至于积累了很多潜伏的风险；
3）跟踪软件版本的演化是一件非常困难的事；
4）对程序的修改，导致了文档的不一致；
......
3、原来的软件质量有缺陷
1）软件本身就有质量问题，只是日常维护已经很不容易，更不要说修改；
2）软件设计时为维护工作考虑得太少，例如对错误给出的提示很不清楚，过分依赖输入数据的正确性；
3）软件的可移植性、可扩展性很差。设备、软件（主要是系统软件）的更新换代对软件的兼容性提出了巨大的考验。可是，有几个软件在设计时充分考虑了可移植性呢？将一套系统从32位机上移到64位机上，即使没有对任何语句进行修改，也必须做全面的测试以保证不会突然当机；
4）软件的易用性不高，必须要专业人员才能维护；
......
4、客户需求不断变化
1）软件更新的速度赶不上需求变化的速度；
2）原来的技术、模式、结构不能满足新的需求；
3）多次变化后连客户也不清楚到底要什么；
4）层层堆叠的补丁给系统带来了预料之外的负担。例如不断增加的、过多的报表降低了系统效率。
......
5、软件开发人员的情绪
1）优秀的程序员都不愿意做系统维护这种枯燥的工作；
2）做系统维护占用的时间可能远远大于做软件开发，但薪水却不是保持同样的比例；
......
那么还有哪些问题是你在软件维护过程中经常碰到的呢？
欢迎大家贡献自己的力量，给我一些参考和建议。
...全文
请发表友善的回复…
发表回复
LunTanZeng 2003-12-08
- 打赏
- 举报
学习！
吸收！！
创新！！！！
吸收！！
创新！！！！
zhulinu 2003-12-08
- 打赏
- 举报
我个人认为逆向工程只适合对现有的软件的结构进行分析和总结,可以发现其中的优点和不足,对自身的提高和对软件的认识是有好处的.对c++的逆向工程,我用的是Rational Rose C++ Analyzer,还挺好用的.对java我知道一个工具TogetherSoft公司的 Together5.5.没有用过,听说挺好的,可以把代码反推成类的结构图.
cloudflashes 2003-12-07
- 打赏
- 举报
同意zhulinu(木木)的论点。在开始维护一个系统的时候，面对的是既成事实，不可能再对开发阶段提什么要求了，关键是用什么办法收拾现在的摊子。而当你维护的是一个有上千万行代码、有几十个前置和上千个终端的系统时，真得有个好的方法才能继续得下去。
现在软件维护对再生工程（reengineering）的讨论很多，如重构、逆向工程和前向工程。从我所了解的情况来看，只有少量的自动工具支持这些工作，而且还只是针对规范的面向对象语言编写的程序。
不知道有没有哪一位在维护中使用了重构或是逆向工程之类的技术呢？
现在软件维护对再生工程（reengineering）的讨论很多，如重构、逆向工程和前向工程。从我所了解的情况来看，只有少量的自动工具支持这些工作，而且还只是针对规范的面向对象语言编写的程序。
不知道有没有哪一位在维护中使用了重构或是逆向工程之类的技术呢？
zhulinu 2003-12-06
- 打赏
- 举报
我同时做过软件开发和维护,深感到维护的麻烦,很多都是历史问题,公司又没有一套正规化的管理,软件工程大家都知道,但是有多少公司能按照他来做呢.其实很多时候不是开发的问题而是怎样简化维护的过程和工作.对bug的维护是一种低级的维护,在维护的时候如何扑获新的需求和对系统的架构怎么实现,怎么合理的实现才是一种高级的维护.个人观点,呵呵
jeffyan77 2003-12-06
- 打赏
- 举报
这方面有很多的理论。前参考一下前人的东西吧。
stonespace 2003-11-30
- 打赏
- 举报
如果维护碰到的问题，都是因为前面开发阶段质量不好导致的，和维护阶段碰到的事情没有多大关系。如果要改善维护的问题，应该提高前面阶段开发的质量。
分析设计编码阶段影响维护成本的质量主要是可读性、可修改性和bug数目。
维护的起因不外有两个，一个是需求变化，这个无法控制；另一个就是发现bug，所以减少bug数目可以减轻维护的负担。
维护要做的事情主要是修改软件，如果不好修改有两个原因，一个是看不懂原来的代码，一个是结构刚性太大，修改一个局部牵动范围太大，增加修改工作量，也会带来新的bug。
减少bug数目的技术很多了，一般来说开发人员经验越多，bug越少。简单的实现方案比复杂的实现方案bug要少。经过review的代码bug比较少。可读性好的代码bug也少。高内聚松耦合的bug比较少。
可读性也有很多影响因素，简单的实现方案比复杂实现方案容易理解，重用程度高的实现比较容易理解，使用模式也比不使用模式容易理解，用常规的解决方案比创新的解决方案容易理解。文档也是越简单，越靠近代码就越容易理解。
可修改性和早期预见的准确性有关，如果早期能够预料到客户会对那些需求提出修改，把拿部分设计的灵活一些，后期维护日子就会好过一些；同样知道哪些部分可能bug比较多，或者方案风险比较大，也可以设计灵活一些。不过每一部分都设计的尽可能灵活，那么软件就会变得不必要得复杂，反而增加维护的麻烦。
具体实现灵活性的方法可以使用设计模式，以及抽象的设计和使用多太性。
分析设计编码阶段影响维护成本的质量主要是可读性、可修改性和bug数目。
维护的起因不外有两个，一个是需求变化，这个无法控制；另一个就是发现bug，所以减少bug数目可以减轻维护的负担。
维护要做的事情主要是修改软件，如果不好修改有两个原因，一个是看不懂原来的代码，一个是结构刚性太大，修改一个局部牵动范围太大，增加修改工作量，也会带来新的bug。
减少bug数目的技术很多了，一般来说开发人员经验越多，bug越少。简单的实现方案比复杂的实现方案bug要少。经过review的代码bug比较少。可读性好的代码bug也少。高内聚松耦合的bug比较少。
可读性也有很多影响因素，简单的实现方案比复杂实现方案容易理解，重用程度高的实现比较容易理解，使用模式也比不使用模式容易理解，用常规的解决方案比创新的解决方案容易理解。文档也是越简单，越靠近代码就越容易理解。
可修改性和早期预见的准确性有关，如果早期能够预料到客户会对那些需求提出修改，把拿部分设计的灵活一些，后期维护日子就会好过一些；同样知道哪些部分可能bug比较多，或者方案风险比较大，也可以设计灵活一些。不过每一部分都设计的尽可能灵活，那么软件就会变得不必要得复杂，反而增加维护的麻烦。
具体实现灵活性的方法可以使用设计模式，以及抽象的设计和使用多太性。
cloudflashes 2003-11-30
- 打赏
- 举报
谢谢“ozzzzzz(希望敏捷)”的阐述。也许，维护是一个很不容易引起大家的讨论兴趣的话题，而且没有多少人是既做软件开发又做维护的。
我在这里再等一个星期吧，看看还有没有人给我再提点建议。
我在这里再等一个星期吧，看看还有没有人给我再提点建议。
rtdb 2003-11-11
- 打赏
- 举报
楼主说得够明白了。
cloudflashes 2003-11-11
- 打赏
- 举报
在座的各位，大家对软件维护都没有什么特别的感受可以和我交流交流吗？
ozzzzzz 2003-11-11
- 打赏
- 举报
1。软件难以看懂。
写清晰的代码，合理的注释，以及够用文档。
不要怕写长的变量和方法名。不要在最开始就把注释都写上去，代码稳定以后再去写吧，免得你修改了代，忘记修改注释。文档这个东西宁可少而精，千万不能大而全。细节的部分直接看代码，总体的思路看文档。设计文档不是你维护需求的东西，那个设计再开发中早就面目全非。你需要一个从代码中提纯出的代码结构说明文档。
2。修改带来不良反映。
至少原来通过的测试都要再次通过。打补丁不一定是最低的节约成本的办法，要是你使用java之类的语言，请实施refactor。跟踪变化是简单的事情，只要你建立了配置管理。如果你要是先搞了一大堆文档，人工保持同步是不可能的。而CASE工具虽然可以保持同步，但是CASE产生的文档可读性又大有问题。所以你还是要先设计，再实施，最后文档的好。
3。原来的软件质量就有问题。
1）为什么会有问题，如果维护的成本大于改造的成本，为什么不改造。
2）你原来的程序经过测试吗？
3）和4）成本问题。而且你怎么能在没有AMD64的时候就去考虑对它的兼容性呢？你现在怎么考虑INTER的64实现呢？易用性是要经过大量的人体工程学研究而达到的，你的客户可以为这个付出额外的打的多的价格吗？
4。需求的变化。
没有变化的需求，我们吃什么？客户的变化是正常的，他们不知道自己到底要什么也是正常的。你需求作的是尽快给他们一个可以运行的软件，看看你理解的和他们想的到底有什么不同。而不是呆在那里等客户的需求稳定下来。
你为什么必须打补丁呢？效率降低是不是应该考虑升级系统？
5。人的情绪问题。
管理的问题有管理的解决办法。
写清晰的代码，合理的注释，以及够用文档。
不要怕写长的变量和方法名。不要在最开始就把注释都写上去，代码稳定以后再去写吧，免得你修改了代，忘记修改注释。文档这个东西宁可少而精，千万不能大而全。细节的部分直接看代码，总体的思路看文档。设计文档不是你维护需求的东西，那个设计再开发中早就面目全非。你需要一个从代码中提纯出的代码结构说明文档。
2。修改带来不良反映。
至少原来通过的测试都要再次通过。打补丁不一定是最低的节约成本的办法，要是你使用java之类的语言，请实施refactor。跟踪变化是简单的事情，只要你建立了配置管理。如果你要是先搞了一大堆文档，人工保持同步是不可能的。而CASE工具虽然可以保持同步，但是CASE产生的文档可读性又大有问题。所以你还是要先设计，再实施，最后文档的好。
3。原来的软件质量就有问题。
1）为什么会有问题，如果维护的成本大于改造的成本，为什么不改造。
2）你原来的程序经过测试吗？
3）和4）成本问题。而且你怎么能在没有AMD64的时候就去考虑对它的兼容性呢？你现在怎么考虑INTER的64实现呢？易用性是要经过大量的人体工程学研究而达到的，你的客户可以为这个付出额外的打的多的价格吗？
4。需求的变化。
没有变化的需求，我们吃什么？客户的变化是正常的，他们不知道自己到底要什么也是正常的。你需求作的是尽快给他们一个可以运行的软件，看看你理解的和他们想的到底有什么不同。而不是呆在那里等客户的需求稳定下来。
你为什么必须打补丁呢？效率降低是不是应该考虑升级系统？
5。人的情绪问题。
管理的问题有管理的解决办法。
