谈谈软件的可维护性问题.docx

谈谈软件的可维护性问题
谈谈软件的可维护性问题-by康华
、八、一
前B
很多包括自己在内的开发人员都会经常去借用（我们不用剽 窃这个词了！呵呵）开源代码进行二次开发；或者在前辈的遗留代码 下，继续修修补补。这种经历往往并不像看起来那么简单一一有时看 懂，进而修改别人的少许代码，都会觉得老虎天一一无从下手，究其 原因主要是代码晦涩，关系复杂，难以隔离影响等。
而这时我们或者抱怨前人代码写的愚蠢，垃圾；或者又会自惭 自己编码水平太次。其实这种困境的起源除了自己笨以外，更多是 因为代码的可维护性不够。
由于前不久和朋友齐永升注释《代码质量》一书时曾关注过 代码的可维护性，而近期又在工作中不断遇到软件需求变更而带来的 代码修改问题，所以这里就我自己对代码维护性进行一点总结，希望 能引起大家注意，以便在以后开 发中能养成好****惯。
软件维护性概念
所谓软件的可维护性其实说简单了就是软件代码的可被修改的容易 程度。如前言所说，代码反复修改的情况不可避免，这种软件的
不断演化过程一一具体就是修正错误；适应新环 境；满足新需求一
一虽然貌似将软件的功能变的越发强大，但是事实上这些改变总是 或多或少的有悖于当初的设计初 衷，因此势必慢慢的蚕食软件的基 础架构和代码质量一一造成的结果是让代码越来越难看懂，健壮性 越来越脆弱，修改一个bug的代价越来越大。
鉴于这个矛盾，Martin Fowler提出的（refactor）代码重构主要 就是从代码编写角度出发，提高代码的维护性，以便能更好适应软 件演化。那么接下来的一个问题是：软件的可维护性 有无标准的评 测方法？学院派早都就此问题给出四个定义一一：可分析性；可改 变性；稳定性；易测性。此刻先别去追究这个几个形而上学的术语 ——后面我会就各点进一步展开，谈谈自己的看法。再次之前，我 们先来看看定量评价可维护性的方法（其实本文重点，不在于此， 你完全可跳过以下两节）o
过程语言的可维护指数首先来来谈谈面向过程语言的可维护性计 算：这里有一个更 貌似深奥的可维护性指数：
Maintainability Index (MI) = MAX(0, (171 - 5. 2 *
In(Halstead Volume) - 0. 23 * (Cyclomatic Complexity)一
* ln(Lines of Code))*100 / 171)
它看似一个对维护性定量分析的精确的数学公式。其实不然。这个 公式无论是系数或者是运算项都是来自于经验规则（你 千万别想着 去推导它）
1.
Halstead是测量代码计算复杂度,具体如果一个程
序有N个操作数和运算符，n个不同的的操作数和运算 符，那么
总之程序中的运算
halstead = N * Log2 (n);
符和操作数越少越利于提高 MI o
Cyclomatic Complexity是代码的逻辑复杂度，程序
的每个可能的执行分支(if, while , for等)都为该指标贡献 1个点。该值的建议范围,最多不超过20o
Lines of code是代码行数。
注意，需要说明的是每个模块，每个文件都可计算维护性指 数，甚至每个函数都可计算，而程序的MI则是其所有 的平均值。
如果你想测试一下你代码的Ml,这样的工具开源的倒是 有一些
(http://wvw. chris-lott. org/resources/cmetrics/ )。这里
给大家推荐一个在Linux下的工具：pmccabe (apt-get install pmccabe 即可安装)可用于计算 Cyclomatic Complexity ,
line of code等。可惜目前计算halstead的开源工具我还没有
发现，不过好像vs
2008的新特性里支持代 码复杂度计算，其中的
各种指标还比较详细，建议大家可试用。
这个来自经验的MI的值越高越好，说明维护性越强。但是毕 竟是经验规则，就如同我们有很多经验说如何买股票 能挣钱，或者 如何打仗能打胜，但是却绝对没有谁说一定这么作就能挣钱或者打 胜仗。所以MI更合理的使用场合的是作为代码重构时的参考，便 于发现那部分代码可能需要重点考虑。而且最好的评价方式是进行 纵向比较，也就是说将你 重构前的代码
MI和重构后的比较，从而 判断重构的积极意义。
面向对象的可维护指标对于面向对象语言而言，可维护性的指标则 更发散，更复杂一些。毕竟面向对象代码的基础单元是对象，而对 象的封装，继承，多态这些特性无不影响代码的可维护性。下面介 绍几个面向对象语言使用的通用指标。
WMC ( weighted methods per class):基于类的加