The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
行代码（也称为 SLoC）是一个声誉糟糕的度量标准。试着通过谷歌搜索一下，你会发现有大量文章抨击它对软件开发过程的反效果和破坏性。主要的论点是我们不能通过编写的代码行数来衡量编程的进展。可能最著名的引用是归功于比尔·盖茨。
基本上，这意味着飞机的某些部分在同样轻便的同时将需要更多的努力（例如像中央计算机这样的部件）。我们不应该测量飞机的重量，而应该测量投入其中的努力…不知怎么办。那么，这就是想法。我们可以用多少次程序员“触碰”这些代码行来衡量。我们将统计实际修改了多少次，而不是计算代码行的数量—我们可以从Git（或任何其他版本控制系统）获取这些信息。你触碰飞机的那个部分越多—你在上面花费的努力就越多，对吗？
我称之为代码触碰（HoC），并创建了一个小工具来帮助我们仅用一行计算这个数字。它是一个Ruby gem，安装它并运行：
54687是您代码库中的代码行数总和。这个数字背后的原理很简单——每当在Git提交中修改、创建或删除一行代码时，计数器就会增加。
这个指标比代码行数（LoC）更好的主要原因是它更好地与实际投入到代码库中的工作相一致。以下是原因。
HoC指标总是在增长。今天它不能比昨天低—就像努力一样，它总是增加的。代码行数不是这样的。今天你可能有一个庞大的代码库，但是在重构后它会变得更小。代码行数减少了。这是否意味着你的效率降低了？绝对不是这样，但是对于非程序员来说，代码行数指标却是如此。例如，项目经理可能会认为，由于代码库的大小在过去一个月内保持不变，团队没有在工作。
HoC没有这种违反直觉的影响。相反，HoC随着每次提交而增长。你越多地在代码库上工作，HoC就越大。你的产品的绝对大小是多大或多小并不重要。重要的是你付出了多少努力。这就是为什么HoC非常直观，并可以用作软件开发进度的衡量标准。
看看这个18个月的图表；它展示了两个指标。我使用了相同的Java代码库rultor，一个DevOps助手。正如你在图表上看到的，代码库在几个月前经历了一次重大重构。我认为很明显，这个图表上的哪个指标更多地告诉我们关于对产品投入的努力。
对于HoC来说，代码库的绝对大小并不重要，而只有你对其的相对贡献有多大。
假设你有30万行代码，其中95％是从第三方库中复制粘贴的（顺便说一下，这是一种非常常见且糟糕的做法——将第三方代码保存在自己的存储库中）。代码行数会很多，但实际自定义代码部分将相对较小。因此，代码行数指标会产生误导性——它总是显示30万行，只是在其周围有小幅增减。每个人都会觉得团队正在处理30万行代码库。
另一方面，HoC始终将考虑到实际被修改的代码部分。HoC的值将与正在处理代码库的程序员的实际工作量客观相关。
LoC通常因其对代码复杂性的中立性而受到批评。一个自动生成的ORM类或一个复杂的排序算法在代码行数方面可能是相同的，但第一个只需要几秒钟就能编写完成，而第二个可能需要几周或几个月的时间。这就是为什么代码行数通常被认为是一个虚假的度量标准。
Hits-of-Code将复杂性考虑在内，因为你使用那个排序算法的时间越长，你对其代码行数进行的修改就越多。嗯，如果你经常使用Git并经常提交更改，那么这个说法是正确的—这是告诉Git你的工作进展的方式。
最后，看看我们团队在过去几年中完成的这个开放项目列表。每个项目都有两个指标：代码行数和代码命中数。有趣的是，相对较小的项目拥有非常大的（超过一百万）HoC数字。这立刻让我想起我们投入了多少时间以及它们的年龄。
在这个分析中，我使用了HoC指标：每行代码的支付费用是多少？那篇文章比较了一个传统项目，每个HoC支付3.98美元，和一个由Zerocracy管理的开源项目，每个HoC支付13分。
我的结论是，Hits-of-Code指标可以用作软件开发项目的进度跟踪工具。此外，它还可以用于团队规模、项目预算、开发进度等的估算。显然，HoC不能是唯一的指标，但与其他指标结合使用，可以在估算、规划和跟踪方面大大帮助。
附注：试试hitsofcode.com。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-28 at 15:42
