自由行

2008-03-20

软件项目摘要

Filed under: 随笔 — thomas @ 10:18

项目统计

目前手头正在研究的一个软件项目。在ClearCase1078个文件,代码文件共220,其它为资源文件(图片、配置文件)

如何来评价一个项目的规模和复杂性呢?俗话说要心中有数,那么就看看各个参数指标的具体数量吧。

下面是Source Insight 3.0生成的报告摘要节选:

Project contains 4902 symbol records, 37549 index entries, and 220 files.

Total Files:          220

Total Bytes:      1896389

Total Lines:        55204

Total Symbols:        782

Item

Value

Classes

138

Type definitions

6

Enumerations

68

Constants

169

Enum Constants

425

Variables

185

Functions

10

Methods

1429

Macros

21

Function Prototypes

68

Method Prototypes

1358

Structure Members

681

Resources

6

Custom Tags

2

从代码行数、类(Classes)、类的方法(Methods)和类的成员变量(Structure Members)。尽管在面向对象的程序设计中人们早已抛弃了行数的指标,但我个人认为整体的规模行数还是一个重要的指标,至少在表述了线性特征,这对于编写程序来说能够反应编码的工作量。

当然55204行可不是一个小数目,10多个人写了几个月。复杂度的评价并不是是一个容易的事,除了数量上的多寡,相互之间的调用关系、运行期的生命期、等等都是重要的影响因素。

另外在目前做一个统计,在以后修改设计后进行对比作一个参考依据。

2008-03-11

你的灯还亮着吗?

Filed under: 思想 — thomas @ 23:48

你的灯还亮着吗?

先要介绍一个故事,摘自温伯格《你的灯还亮着吗》。

——————————————————————————————–

13 隧道尽头的灯

最近,在日内瓦湖上的山脉中,建成了一条很长的汽车隧道。在投入使用之前,总工程师想起来,她忘了警告汽车司机在进入隧道之前把车灯打开。尽管隧道的照明设施很好,仍然需要预防停电的情况下发生灾难(在深山中这种意外是很可能发生的)。

于是人们做了一个标牌,上面写着:

警告:前有隧道请打开车头灯。

他们把标牌挂在隧道入口处,然后隧道如期通车了。既然问题已经解决了,大家都觉得很轻松。

从隧道东出口再往前400就是世界上风景最优美的度假胜地,从这里俯瞰,整个日内瓦湖都尽收眼底。每天都有成百上千的游客在此处欣赏美景,放松他们疲惫的身体,也许享受一个美味的小野餐。同时,每天当这几百名神清气爽的游客返回他们的汽车的时候,都会有十来个或者更多的人们意外地发现汽车电池没电了――因为他们忘了关掉车灯!警察们被迫用上他们所有的资源,好让车启动起来,或者把它们拖走。游客们怨声载道,并且赌咒发誓要劝说他们所有的朋友都不要到瑞士来旅行。

像往常一样,我们会要求您暂停一下,回答这个问题:

这是谁的问题?

a)司机

b)乘客(如果有的话)

c)总工程师

d)警察

e)州长

f)汽车俱乐部

g)以上都不对

h)以上都对

这种类型的问题中――因为它有一个明确的设计者或者叫工程师”――有一个很强的倾向就是认为这是她的问题。在这件事中,不仅司机们认为这是工程师的问题,而且工程师可能也这么认为。建筑师、工程师和其他设计者的职业道德中有这样一条:他们必须做好所有的事情。

在这个例子中,工程师考虑了她能够强加在司机及其乘客身上的很多种解决办法:

1)她可以在隧道尽头里一块标牌,写上:关掉车灯,但是这样的话夜晚行车的人们也会关掉车灯????

2)她可以装作不知道,顺其自然????不,这本来就是现状,并且政府官员们认为工程师的工作做的一团糟。

3)她可以在风景俯瞰处建造一个充电站。但是要维护要花很多钱,并且如果它出了故障人们会更加恼火。

4)她可以授权一家私人公司经营充电站。但是这会使风景区变得商业化,这是政府和游客绝对不会接受的。

5)她可以在隧道尽头树立一个表意更明确的标牌。

凭借她的直觉,工程师认为一定可以通过某种方法来书写一个更加明确的标牌。她尝试了许多备选方案,最终得到了一个体现瑞士式简约的杰作:

如果这是白天,并且如果您的车灯开着,那么熄灭车灯;如果天色已晚,并且如果您的车灯没开,那么打开车灯;如果这是白天,并且如果您的车灯没开,那么就别打开;如果天色已晚,并且如果您的车灯开着,那么就别关它。

等人们读完这个标牌,汽车早已经飞过围栏,并且咕噜咕噜地沉到湖底了――这根本就不是一个可以接受的解决方法,难道说,还应该说说葬礼该怎么样?必定有更好的方法!

事实上总工程师并没有把问题复杂化,她用了一种方法,把问题当作他们的问题”――工程师只是起了一点辅助作用。她假设司机们非常愿意解决这个问题,但是也许需要一点儿提醒。她还假设司机们――如果他们通过了驾驶执照的考试――不可能是那种彻头彻尾的傻瓜。他们所需要的只是在隧道尽头加一块标牌,写上:

您的灯亮着么?

如果他们连理解这种提醒的能力都没有,他们遇到的麻烦就不只是电池没电这么简单了。这个标牌使问题消失了,而且因为这条信息足够短,所以在标牌上可以很多种语言把它表示出来。工程师会永远记住她在这次工作中学到的一课:

如果人们的灯真的亮着,一个小小的提醒可能比你那些复杂的解决方法都更有效。

那么,您的灯亮着么?

——————————————————————————————–

这个故事中提到一些问题:这是谁的问题?

当然文中给出了一些分析,并且提出了一个相对简易的解决办法。我个人以为这个问题应该进一步的分解。文中的问题是一个复合问题,不是一个单纯的问题。所以分析时可以从

1.涉及的人或者方面;

2.谁能解决,怎么解决?

12的基础。工程师最初提示通过隧道的司机开灯,是为了解决安全性问题,即:如果不开灯,有可能在隧道突然停电时发生撞车等交通事故,称作问题1。而开灯通过隧道必然会消耗电池的电量,即:消耗电池电量获得安全。工程师也隧道的设计者,而司机则是隧道的用户。

如果司机通过之后关了车头灯,那么就不会出现电量不足开不了灯的问题。实际情形是大部分司机都忘记了通过隧道后关灯,所以才会产生问题,姑且称作问题2。为了解决问题2,“警察们被迫用上他们所有的资源,好让车启动起来,或者把它们拖走。”警察为了解决问题2,导致“游客们怨声载道,并且赌咒发誓要劝说他们所有的朋友都不要到瑞士来旅行”,称之为问题3,这给当地政府部门造成不良的影响。问题2的条件是问题1的解决办法:提示通过隧道的司机开灯+通过隧道后忘记关灯,造成电池电量继续消耗。作为警察、州政府来说他们面临的是问题3

解决问题2,需要从造成问题2的两个条件入手。

1)她可以在隧道尽头里一块标牌,写上:关掉车灯,但是这样的话夜晚行车的人们也会关掉车灯????

2)她可以装作不知道,顺其自然????不,这本来就是现状,并且政府官员们认为工程师的工作做的一团糟。

3)她可以在风景俯瞰处建造一个充电站。但是要维护要花很多钱,并且如果它出了故障人们会更加恼火。

4)她可以授权一家私人公司经营充电站。但是这会使风景区变得商业化,这是政府和游客绝对不会接受的。

5)她可以在隧道尽头树立一个表意更明确的标牌。

1)从第二个条件入手,但是夜晚行车的情形有冲突;

2)逃避问题2

3)从问题2的结果入手,恢复电量消耗,会带来维护问题;

4)还是从问题2的结果入手,商业化给政府和游客带来负面影响;

《你的灯还亮着吗》前面阐述了问题的链索的分析方法,在这里是一样的。

问题相互影响,前面的结果构成后面问题的条件。一个问题的解决方法中可能会引入新的问题。这就是复合问题的特征。

通过综合分析,发现在通过隧道后关灯是最好的方案。当然辅助的提示需要司机做灵活的处理。让司机根据经验来判断,从而做出具体的处理,关灯还是继续开着,即:

如果这是白天,并且如果您的车灯开着,那么熄灭车灯;如果天色已晚,并且如果您的车灯没开,那么打开车灯;如果这是白天,并且如果您的车灯没开,那么就别打开;如果天色已晚,并且如果您的车灯开着,那么就别关它。

这就是我们期望的结果,而且易行。有时候我们使用产品的方式不正确,说不定会产生不好解决的问题,所以纠正一下就行了。

您是否正确的使用了产品,你的灯是否还亮着呢,是否还在抱怨别的人或方面呢?

Powered by WordPress