软件模块的可测量性

今天一个朋友看完我的blog, 问我: 你能说说CC和OO metric对我们实用主义者的指导作用吗? 我整理了和他的谈话内容，发布在这里。题目就叫软件模块的可测量性(Software Module Measurability)。

Measurability在偏向理性的一些分析方法里面是很重要的。比如marketing里面ROI的分析；客户服务系统里面客户忠诚度的分析。这里我们简单说两个方面。

   1. 怎么做到measurability? 简而言之，当我们明确要测量目标后，接着就是建立数学模型，然后提取特征属性(feature).
   2. 怎么利用measure的结果? 我从两方面来回答. (a) 某次的测量值和预设定的阈值作比较，通常它会警告你某个重大时刻是否到来。(b) 把每次的测量值保存做一个时间序列，那么可以用来调整原来的阈值。不难看出这是一个反馈系统。

下面是我和我朋友的一段对话:

    我: 一般你们什么时候会做refactoring?
    朋友: codes smell bad…
    我: 那么你根据什么来说这些代码是bad smell?
    朋友: 感觉，或者就是可以观察到的…

Well, 我朋友说的感觉，我更多的理解是”经验”。然而经验有时候让决策变得”迟钝”或者”不准确”，因为team member在变，自动化工具在变。但是如果考虑到软件模块的可测量性，有些回答我们可以更加有信心。回到对话场景，决定一个软件模块是否要refactoring. 一般我会去看测试覆盖率的度量，重复代码的度量和前面说的一些OO metric. PM/team leader可以参考这些数据来安排refactoring的schedule.

最后，一个优秀的software team应该:

   1. 保持一份最新的软件模块的可测量性报告.
   2. 分享给每一个team member.
   3. 保持一份最新的schedule.

author: Jack
orignal: http://jack.lifegoo.com/?p=10

... ...可测试覆盖率本身和是否需要重构有什么必然得关联呢？
@.@||~

我想你是对的，覆盖率和是否需要重构没什么必然的联系:)

我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
1.前者成本太高
  虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾.

2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真.

Clamp, 我要表达的主要意思不是说成为主流或者成为决策的主导因素。我觉得应该去动态的理性的跟踪一个项目的状态，至少某些数据能够对你的决策有所参考。当然我们还在慢慢的实践，当进入一个良性循环，我想数据应该可以说明某些方面的问题

即使有实验数据出来，我觉得那也是一种参考，而不是标准或者流程的

恩，关键在于“某些数据”到底是什么？
我个人现在用的项目测量数据只包括以下几个：
    自从第一次正式集成测试以后的内部BUG曲线（分等级）
    自从第一次用户参与的集成测试以后的用户问题曲线（分类）
    这里确定等级和分类是一个很麻烦的事情

关于逻辑复杂度。楼主的帖子给出的Link不错，只是简单了些。

条件语句，循环语句都是逻辑分支语句。if else, switch case, for while都代表逻辑分支。
逻辑分支是针对可能执行路径而言的——某一块代码指令是否能够被执行。逻辑分支语句下面的子代码块，有可能被执行（1 – n次），也有可能不被执行（0次）。条件语句if else, switch case,下面的子代码块有可能被执行0次，或者1次；循环语句for while下面的子代码块有可能被执行0次，或者n次。

一个逻辑分支，就代表两条可能执行路径。可能执行路径数目的增长，相对于逻辑分支的个数来说，是指数增长。比如一个method有n个逻辑分支，那么可能执行路径数目就是2的n次方。
注意，if else和if一样，都是一个逻辑分支。所以我们不需要把else的个数计算在内。
同理，
if 
else if
else if
else
这段并列else if的代码里面包含了3个if, 那么有三个逻辑分支。
逻辑分支的个数 = if的个数 + (switch) case的个数 + for, while的个数。
我们只需要一个词语搜索计数工具，就可以查出一段代码包含的逻辑分支的个数。

奇怪，好象帖子串了？

没有串，你从楼主的帖子Link看进去，就知道了。
楼上难道没有点进去看？那才是关键。
不过似乎大家都在关注那报告，schedule之类的管理内容。
这也是对的。和老板讲逻辑没用，就要讲这些report，schedule。

除了逻辑分支，更重要的衡量标准是参数的个数。
更准确一些，是整个输入信息的个数，包括参数，用到的成员变量，环境变量。
增加一个输入参数，就是增加了整整一个变化维度。