前提：

真实世界物体和代码的测量系统是不同的。虚拟系统测量方法经过多年的发展。但它们适合当今世界吗？

代码度量系统和度量依赖于编写代码的质量和语法。

随着现代系统硬件CPU的速度每年呈指数级增长，开发人员可以更快地运行代码，计算也更容易。

那么，大数据和云计算，我们还需要像以前那样度量代码吗？

现实生活中的测量系统：

在现实生活中，我们测量的一切都是从参考演变而来的。重量、体积、高度所有测量单位均以参考为基础。

我们如何计算5米的高度？

国际单位制（SI），俗称公制，是国际计量标准，1875年5月20日，包括美国在内的17个国家在巴黎签署了《国际计量条约》，现在全球都把它称为"世界计量日"。

所以，如果我知道1米，5米是5倍以上，因此根据上述条约，1米是纯计量单位。

导出的数学计量。

导出的单位与导出的量相关联；例如，速度是从时间和长度的基本量导出的量，因此国际单位制导出的单位是米每秒（符号m/s）。导出单位的尺寸可以用基本单位的尺寸来表示。

因此，对于任何测量技术，都可以使用参考或基线来确定某个事物的好坏。

虚拟系统测量：

在计算机系统中有几个既定的标准。E、 g.–内存大小或标准度量单位（MB、GB、TB）。CPU速度是以每秒执行的周期数来衡量的，单位为千兆赫（GHz）。

这让我想到了代码的标准是什么。我们真的有测量系统和标准吗？它们是为了跟上当今世界的发展而进化的吗？是否应该效仿它们？

让我们谈谈代码测量实践：

基于代码质量。基于代码性能。提高缺陷率。

基于质量：

基于质量的测量是针对使用最佳实践制定的标准。在编程世界中，质量的定义是不断演变的，云购，大数据是数据，并且可以因市场和客户而异。

基于代码性能：

代码的性能是为了改善用户体验，优化代码或计算时间可以更低。在SAP world trace中，运行时事务分析SAT、SE30、ST01、ST05、ST12有助于衡量性能。

开发缺陷比率。

客户业务需要平稳运行。每一个开发与缺陷数量的对比都用来确定一个代码块有多好。

测量工具：

以我的经验，任何一个ERP客户都会使用一些工具和治理来尝试控制代码质量。

即使有以上所有的情况，大数据治理平台，任何系统都会有坏代码/好代码，俗话说"系统和系统一样好"维护他们的人"。当涉及到代码质量和管理时，最重要的还是人类的创造力。

自动化系统：

自动化部署和代码审查不再是新事物，代码质量门扩展的代码检查器是减少手工工作和减少错误的好方法。

荣誉奖：

HANA建议：

1912445–ABAP定制针对SAP HANA的代码迁移—针对SAP HANA迁移的建议和代码检查器变体

结论：

让我们尝试定义一个系统/流程，用于测量ERP系统中的代码。为了简单起见，我将其称为"代码度量索引"。

代码度量索引只是一个基于点的系统。为系统中的每个应用程序计算代码度量的多维平均值。

这可以是ABAP中的一个简单客户程序，它可以为您计算该值，以指示系统的好坏。我使用以下参数进行计算。在本例中，我使用的是t恤尺寸。

代码行：

代码块/代码单元中的行数（代码单元可以低至子例程，联通物联网，高至系统本身）。

继承：任何面向对象的代码测量都应具有继承数。

嵌套语句：类似IF–ELSE块大小写的嵌套代码语句ENDCASE.

SQL Time:X，Y图形Y为所选记录的数量X所用时间。曲线应在30度以下，以获得最佳的表现。

最后：

就像人类智商测量。代码并没有太大的不同，它几乎就像一个由逻辑构建的活的有机体，随着时间的推移而变化和进化，就像我们一样。它有多个维度和多个参数。

随着系统越来越复杂，硬件的速度越来越快，比以往任何时候都更需要确保这些系统中的代码运行更高效，更易于维护。

代码质量的度量，性能等不会消失，但它们可以随着发展而简化，但这是一个持续的过程，在不同的组织中是不同的。

最后，保持代码审查和质量的过程简单，因为简单的过程总是创造智能行为。