编码消耗率CCR，“上帝代码”，反射，简洁代码

在前文（ (32条消息) 陈旧语法密度之六——用Map消灭if-else if-else，“上帝代码”_陈勇的博客 - Scrum 敏捷开发培训咨询，绩效管理，团队管理，《火星人敏捷开发手册》-优快云博客）中，笔者曾经提到一些实现每功能点所需代码行数的数据。时过境迁，现在重新修订一下当年的数据。

修订的主要信息源是2016年Capers Johns的《软件工程通史》发布的国际数据，以及笔者近年来咨询过的企业的真实团队数据。值得欣喜的是，所有数据均有大幅度改善。

功能点定义

这里所说的功能点是一种国际标准，它大致定义是：

功能点FP = 接口数 * 5.4 * 应用类型调整因子。

接口数大致等同于swagger ui中的接口数量，故可以自动获取。

5.4是历史原因造成的一个常数。

“应用类型调整因子”是众多调整因子中起决定性作用的一个。大致可以取值为：

OA类=1.0，多个应用集成=1.2，图表=1.3，一般金融=1.8，通信软件=1.9，嵌入式=2.0

其他未提及的应用可通过对比找到大致数值。

同一类型的应用尽管会有所不同，但从大数定理的角度看，其软件的复杂程度相当。实际上上述调整因子的数值本身就来自业界统计数据，也会随着业界的变化而变化。

编码消耗率CCR

编码消耗率表明了完成相同功能（包括正常和异常功能）所需的逻辑代码行数，其定义为：

编码消耗率CCR = 逻辑代码行数LLOC / 功能点数 FP。

CCR是Code Consuming Rate的缩写，此概念在国内几乎无人提及，但在国外的研究较多。究其原因，很大程度上是国外要通过CCR来研究不同语言语法、框架的设计与演进，对代码简洁性的影响，从而设计出下一版本的语言语法（甚至一种新语言）。

注意CCR不是一个通用的名词，国外的众多研究者并未为其命名（或虽命名但未流传），这个名字是笔者自己起的。

编码消耗率越低，则代码的精美程度越高。一半代码几乎意味着：一半的打字时间，一半的工作量，一半的缺陷，远低于一半的维护工作量。

此外，逻辑行而非物理行的定义中包括了对自然语言的尊重，所以将两行代码合并到一行，或将所有变量名都改成一个字母这些奇葩方法，并无助于降低CCR。删除错误处理代码以降低CCR也是不可行的，因为CCR是实现“相同功能”所需的代码行数。

上帝代码

指理想的，多一个字符则多，少一个字符则少的代码。

多数人都不相信存在上帝代码，这是因为多数人的代码距离上帝代码非常遥远。如果不长途旅行，人类就意识不到地球是圆的（东西方向旅行足够远会发现时差，南北方向则会发现气温甚季节变化，实际上最早计算出地球直径的就是古罗马时期一位去过埃及南部的旅行者）；不发明望远镜，人类也意识不到地球乃至太阳不是宇宙中心。

在充分使用面向对象、设计模式等方法时，高手的代码与上帝代码“