经过了一段时间的徘徊，从苡瑄那里得知 USC 的指导研究项目今年夏季学期依旧继续，于是尝试报了名；感谢包括 Eliena 在内的所有人给了我一个机会，得以不限于教育学学生的身份参加 CSSE 的研究。我先前并无软件工程的准备知识，只做过一点项目管理的工作，这次可以稍稍深入一点地研究软件度量相关的知识，我觉得很开心。于是想把自己看到想到的写下来，单纯记录也好，与人裨益更佳；若是有人指点就更好了。
软件度量伴随着软件工程的发展而发展，其目的核心与项目管理并无多大区别：其特征在于量化作为工程项目的软件的诸多特征（诸如成本、效能、缺陷），以帮助参与项目的所有人，尤其是项目主导负责人们在软件的生命周期里作出正确的决定。
影响软件度量的事件中，比较有影响力的是 1964 年由 Gene Myron Amdahl 担当架构师（也就是阿姆达尔定律的提出者），由 Frederick P. Brooks, Jr. 担当项目经理的 IBM System/360。为了开发这台电脑，IBM 新招了 6 万名员工，还新开了 5 座工厂；其项目也是雄心勃勃的——他们要藉 OS/360 一统 IBM 的系列产品，告别按电脑型号定制操作系统的旧时代。
作为蓝色巨人倾国之力打造的里程碑式的作品，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 的项目来衡量开源社区参与者对于一个项目的贡献程度，看了看感觉很有意思——因为从哲学上，软件度量都是自上而下的，若是从自下而上试试，也可能会有一条新路。
接下来我打算介绍的是软件度量的既成方法论和变化过程，并看看关于软件行数分析和代码复用有什么可以讲的东西；如果有感兴趣的文章或者点子，请多多指教啦/