软件维护性

恰水打球

在介绍软件可靠性时，曾经说起过软件可靠性的时间相关性，软件的失效率往往不会随时间单调下降，那实际情况究竟是怎样的？看看下图就明白了。



硬件、软件的故障曲线

硬件在刚开始使用时会有一个短暂的磨合期，此时出现的故障大多数与使用习惯和熟练程度有关；进入正常使用期后，故障率将会减少并长期保持稳定；等设备老化到寿，故障又会增多，越接近报废，故障率越高。
软件由于不存在老化问题，理想状态下，应该是越用越稳定；但实际情况却是，只要存在升级维护，就有可能引入新的问题，一次大的升级可能意味着会带来一版近乎于重写的软件，随着系统升级次数越来越多，参与修改的人越来越多，大量的冗余代码、错误注释充斥其中，机关遍地危机四伏，软件故障率越来越高，最终只能是推倒了重来。这些就属于软件维护性不高的表现。
<hr/>GB/T 16260《软件工程 产品质量》对软件维护性的定义是：可被修改的能力，包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。
软件维护性包含4项子特性：易分析性、易改变性、稳定性以及易测试性。
一、易分析性和易测试性

易分析性：可被诊断自身的缺陷/失效原因或标识其待修改部分的能力。度量项包括：

• 失效诊断的准确性：是否能够有效的定位失效
  
• 失效诊断的时间：有效定位失效的时间
  
• 有效线索比例：能否提供充分的有效维护线索以支持维护实施
  
• 可理解线索比例：维护过程提供的线索能否被正确、有效的理解
  
• 审核追踪能力：当系统和软件失效后，能否容易的被标识出失效的具体原因
  

易测试性：使已修改的软件能被确认的能力。度量项包括：

• 可自动测试性：是否可以通过软件的自动测试来完成
  
• 测试的重启性：系统与软件在维护后能否成功地在原检查点执行测试
  
• 维护的完整性：修改后的软件是否修复或纠正或完成需求中提出的要求
  

从子特性的度量项可以看出，易分析性和易测试性与软件可测试性的要求实际是一致的，不了解的朋友可以看看专栏里的软件可测试性，本文就不再重复了。
二、易改变性和稳定性

易改变性：使指定的修改可以被实现的能力。度量项包括：

• 代码的可修改性：维护实施方能否通过修改代码来维护指定的功能
  
• 可配置性：维护实施方能否容易地变更配置参数来实施修改
  
• 变更周期的效率：发生问题时，能否在可接受的时间内得到解决
  
• 修改实施的效率：维护过程能否在可接受的时间内得到解决
  
• 修改的复杂度：维护过程的难易程度
  
• 修改的可还原性：完成修改后，是否可以正常还原到修改前的状态
  
• 变更控制的能力：用户能否容易的标识修订的版本
  

稳定性：避免因软件修改而造成意外结果的能力。度量项包括：

• 变更成功的比率：失效是否被修复
  
• 修改影响的局部化：局部维护对于整体的影响
  

注意：GB/T 16260中所定义的稳定性是指系统整体不受局部修改影响的程度，与平时所理解的运行稳定是不一样的。
从子特性的度量项可以看出，易改变性和稳定性关注的实际上是程序设计问题。那么如何避免陷入本文开头所说的那种机关遍地危机四伏的境地，如何让我们的代码阅读时更加优雅和精彩、修改时更加轻松和愉快、运行时更加可靠和快速？这个问题比较复杂，因此我只能继续甩锅了，还是推荐几本书吧^_^。

• 《设计模式：可复用面向对象软件的基础》
  
• 《设计模式之禅》、《大话设计模式》、《研磨设计模式》
  
• 《重构 改善既有代码的设计》
  
• 《大话重构》
  

设计模式+重构=更优秀的程序

设计模式从设计的角度出发，强调分析与思考，是从上到下的过程，从问题到分析设计再到最优答案。重构更多的是从代码和优化角度出发，强调先动手以及有错就改，是从下到上的过程，从问题到一般答案再到优化再到最优答案。



设计模式和重构，对于任何一个开发人员应该都不陌生，本文就不废话了。最后推荐一篇文章：《房间里的大象》是 Apache基金会副总裁Niclas Hedhman在2016中国开源年会上做的演讲，文中揭露了软件业界的七个神话，建议开发人员保持简单、直接，写正确的代码，快一点写，让代码跑起来，大家感兴趣的可以看看。



“房间里的大象”是英语中的一种表达，指的是那些没有人敢谈论却又很明显的事情

诚信之举

不错 支持下