【Meanwhile in LA】0 关于软件度量的入门知识

经过了一段时间的徘徊,从苡瑄那里得知 USC 的指导研究项目今年夏季学期依旧继续,于是尝试报了名;感谢包括 Eliena 在内的所有人给了我一个机会,得以不限于教育学学生的身份参加 CSSE 的研究。我先前并无软件工程的准备知识,只做过一点项目管理的工作,这次可以稍稍深入一点地研究软件度量相关的知识,我觉得很开心。于是想把自己看到想到的写下来,单纯记录也好,与人裨益更佳;若是有人指点就更好了。

软件度量伴随着软件工程的发展而发展,其目的核心与项目管理并无多大区别:其特征在于量化作为工程项目的软件的诸多特征(诸如成本、效能、缺陷),以帮助参与项目的所有人,尤其是项目主导负责人们在软件的生命周期里作出正确的决定。

影响软件度量的事件中,比较有影响力的是 1964 年由 Gene Myron Amdahl 担当架构师(也就是阿姆达尔定律的提出者),由 Frederick P. Brooks, Jr. 担当项目经理的 IBM System/360。为了开发这台电脑,IBM 新招了 6 万名员工,还新开了 5 座工厂;其项目也是雄心勃勃的——他们要藉 OS/360 一统 IBM 的系列产品,告别按电脑型号定制操作系统的旧时代。

IBM System/360 Model 91
One model from IBM System/360 family, retrieved from https://matt.blog/2013/03/08/an-ibm-system-360/
IBM System/360 Models, retrieved from https://en.wikipedia.org/wiki/IBM_System/360

作为蓝色巨人倾国之力打造的里程碑式的作品,OS/360 的血脉流淌在 IBM 此后的每一个大型系统中;而自然,其代价也是昂贵的——这毕竟是人类历史上少有的大型项目,其中遇到的技术之外的困难是众多、难解却弥足珍贵的。Frederick P. Brooks, Jr. 把开发 System/360 和 OS/360 的历程、阻碍和思考在1975年写成了一本书:《The Mythical Man-Month: Essays on Software Engineering》,中文译本标题比较草,叫《人月神话:软件项目管理之道》——“人月”指的是“一个人要花几个月才能开发完一个系统的功能单位”,这是当时衡量软件工时的一个潮流;而神话这个词翻译得就不好了,因为 Mythical 指的是 “迷惑性且不可实现的”。书中的第二部分,便是阐明了人数和必要工时间的非线性关系,指明了人月标准的错误。这和书中的诸多思想一起,成为了对软件工程和软件度量的重要探索基础。

关于软件度量的成文专论,要晚在 1976 年才出版;因为最早的软件度量,是机械地度量行数,看起来没什么必要去写什么专论。有同学可能就要问了,为什么是量行数?你看我 10 行就能解个八皇后问题,遇到不会写 for 循环搞出一万行代码的人我不是亏了嘛;答案很简单——那时的代码可不是我们这种高级语言,都是些指令长度固定、指令集简单、甚至不需要编译器执行、再甚至要打在卡片上的代码。一行代码几乎严格地表示一个操作,也没有什么 attribute 之类的 “标记”,数行数也不是一个大问题;但是后来程序可以用更精简、非面条式的语句执行复杂的结构,单纯地数行数也就没有用了。于是从第一个新概念 “逻辑行数 (Logical Line of Code, LLOC)”对立于“物理行数 (Physical Line of Code)” 开始,人们对软件度量的技术,即“量化能力”提出了新的要求。

根据 Norman F. Schneiderwind 的描述,立体的软件度量包括六个方面:Association、Consistency、Discriminative Power、Tracking、Predictability 和 Repeatability,以 Non-parametric Statistical Method 衡量之。软件度量的五条路径分别是:Function Points、Reliability Reports by Programmers、Halstead Operator Count(For PASCAL)、Metric-based Classification Trees 和 Evaluation of Metrics against Syntactic Complexity Properties。时至今日,很多公司在说的 6-Sigma 以致 CMMI 也是软件度量涉及的东西。

但是在开始软件度量的知识之前,我们要问一个问题,不如说每次打算度量软件或项目之前都必须问一句:我为什么要做软件度量?

比如说我手上有个水壶,我往里倒水,打开炉子,然后想让你告诉我水的温度是多少。

如果你打算用温度计或者测温枪啥的,我建议你再想想——为什么不先问问我烧水做什么呢?如果我想泡个面,那看冒泡了水就开了,没有必要用温度计;如果我拿着上好的抹茶,要严格的87度来泡,那测温枪都不一定好用,你可能会把我的水壶换成恒温慢煮锅才行。

在软件行业里,去量度一个工程,可是远比跑去找个温度计复杂得多,贵得多的。项目一开,公司大门一开,每一秒都带着成本;量度工程需要的心力物力,也自然极为庞大。很多公司的项目主管,接触了软件度量的概念,便为了量化而量化,为了标准而标准,从而造成不必要的开销和损失,这便是“度量陷阱”的一种。作为软件度量的第一步,是千万不要被繁复的数学游戏和标准方法迷了眼睛,要时刻记住自己需要的是什么;更不要奉量化准则为圭臬——有些公司连拿来做量化参照的数据都没攒够,就别搞那些花里胡哨的东西了。

软件度量一直以来,都在关注生命周期内的软件本身。对于贡献者的分析和量化则是后来才有的事。前段时间参加了 ETHDenver 2020 的 BUIDL Week,有见到一个叫 SourceCred 的项目来衡量开源社区参与者对于一个项目的贡献程度,看了看感觉很有意思——因为从哲学上,软件度量都是自上而下的,若是从自下而上试试,也可能会有一条新路。

接下来我打算介绍的是软件度量的既成方法论和变化过程,并看看关于软件行数分析和代码复用有什么可以讲的东西;如果有感兴趣的文章或者点子,请多多指教啦/

Leave a Reply

Your email address will not be published. Required fields are marked *