锁定老帖子 主题:软件模块的可测量性
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-09-20
CC和OO metric对我们实用主义者的指导作用吗? 我整理了和他的谈话内容,发布在这里。题目就叫软件模块的可测量性(Software Module Measurability)。
今天一个朋友看完我的blog, 问我: 你能说说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 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2006-09-20
... ...可测试覆盖率本身和是否需要重构有什么必然得关联呢?
@.@||~ |
|
返回顶楼 | |
发表时间:2006-09-20
Expression 写道 ... ...可测试覆盖率本身和是否需要重构有什么必然得关联呢? 我想你是对的,覆盖率和是否需要重构没什么必然的联系:)@.@||~ |
|
返回顶楼 | |
发表时间:2006-09-21
我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
1.前者成本太高 虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾. 2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真. |
|
返回顶楼 | |
发表时间:2006-09-21
clamp 写道 我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
Clamp, 我要表达的主要意思不是说成为主流或者成为决策的主导因素。我觉得应该去动态的理性的跟踪一个项目的状态,至少某些数据能够对你的决策有所参考。当然我们还在慢慢的实践,当进入一个良性循环,我想数据应该可以说明某些方面的问题
1.前者成本太高 虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾. 2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真. |
|
返回顶楼 | |
发表时间:2006-09-21
即使有实验数据出来,我觉得那也是一种参考,而不是标准或者流程的
|
|
返回顶楼 | |
发表时间:2006-09-21
hijack 写道 clamp 写道 我觉得在很长的一段时间内,通过一个理论模型(即使这个模型是不断完善的)进行量化的测量仍然不会是主流,主流的估算方式仍然是专家经验.
Clamp, 我要表达的主要意思不是说成为主流或者成为决策的主导因素。我觉得应该去动态的理性的跟踪一个项目的状态,至少某些数据能够对你的决策有所参考。当然我们还在慢慢的实践,当进入一个良性循环,我想数据应该可以说明某些方面的问题1.前者成本太高 虽然CMMI把原来4级的定量管理调整到了2级,但我认为这只是为了迎合传统管理者的胃口,没有可描述可定义的过程,根本就没有一个可以适用的模型,而没有模型指导的数据就是一堆垃圾. 2.软件创新因素太多,重复性少,人员差异大,造成外在环境变化太大,单纯依靠定量估算很容易失真. 恩,关键在于“某些数据”到底是什么? 我个人现在用的项目测量数据只包括以下几个: 自从第一次正式集成测试以后的内部BUG曲线(分等级) 自从第一次用户参与的集成测试以后的用户问题曲线(分类) 这里确定等级和分类是一个很麻烦的事情 |
|
返回顶楼 | |
发表时间:2006-09-22
关于逻辑复杂度。楼主的帖子给出的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的个数。 我们只需要一个词语搜索计数工具,就可以查出一段代码包含的逻辑分支的个数。 |
|
返回顶楼 | |
发表时间:2006-09-22
buaawhl 写道 关于逻辑复杂度。楼主的帖子不错,只是简单了些。 条件语句,循环语句都是逻辑分支语句。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的个数。 我们只需要一个词语搜索计数工具,就可以查出一段代码包含的逻辑分支的个数。 奇怪,好象帖子串了? |
|
返回顶楼 | |
发表时间:2006-09-22
没有串,你从楼主的帖子Link看进去,就知道了。
楼上难道没有点进去看?那才是关键。 不过似乎大家都在关注那报告,schedule之类的管理内容。 这也是对的。和老板讲逻辑没用,就要讲这些report,schedule。 除了逻辑分支,更重要的衡量标准是参数的个数。 更准确一些,是整个输入信息的个数,包括参数,用到的成员变量,环境变量。 增加一个输入参数,就是增加了整整一个变化维度。 |
|
返回顶楼 | |