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，安装它然后运行：
$ gem install hoc
$ hoc
54687
54687是你代码库中的代码行数总和。这个数字背后的原理很简单，每当在一个Git提交中修改、创建或删除一行代码时，计数器就会增加。
这个度量指标比代码行数更好的主要原因是它更加与实际投入的工作量相一致。以下是原因。
It Always Increments
HoC指标总是上升的。今天它不能比昨天更低——就像努力一样，它总是增加的。代码行数不是这样的。你今天可能有一个庞大的代码库，但在重构后它会变得更小。代码行数减少了。这意味着你的效率更低吗？当然不是，但对于非程序员来说，代码行数指标是这样的。例如，项目经理可能会认为，由于代码库的大小在过去一个月内保持不变，团队没有在工作。
HoC没有这种逆向效果。相反，HoC会随着每次提交而增长。你在代码库上工作得越多，HoC就越大。你的产品的绝对大小无论是大还是小都不重要。重要的是你投入了多少努力。这就是为什么HoC非常直观，并可以作为软件开发进展的衡量标准的原因。
看一下这个18个月的图表；它展示了这两个指标。我使用了与rultor相同的Java代码库，一个DevOps助手。正如你在图表上看到的那样，代码库在几个月前经历了一次重大重构。我认为这张图上哪个指标更能告诉我们关于产品所投入的努力。
It Is Objective
对于 HoC（Higher-order Component），代码库的绝对大小并不重要，而仅仅关注你对其相对贡献的大小。
假设你有300K行代码，其中95%是从第三方库中复制粘贴而来的（顺便说一句，这是一种非常常见且糟糕的做法——将第三方代码保存在自己的代码库中）。代码行数会很多，但实际的自定义代码部分相对较小。因此，代码行数这个度量标准会产生误导性——它总是显示300K，只会在此基础上略微增加或减少。每个人都会有一种感觉，认为团队正在处理300K行的代码库。
另一方面，HoC 将始终考虑到实际被修改的代码部分。HoC 的价值将与实际与代码库一起工作的程序员所付出的努力客观地相关联。
It Exposes Complexity of Lines
LoC通常因其对代码复杂性的中立性而受到批评。一个自动生成的ORM类或一个复杂的排序算法在代码行数上可能相同，但前者只需几秒钟即可编写，而后者可能需要几周甚至几个月的时间。这就是为什么代码行数通常被视为一种虚假的度量标准。
Hits-of-Code 是考虑复杂性的，因为你使用排序算法的时间越长，对其代码行的修改就越多。嗯，这个说法是对的，如果你经常使用 Git 并频繁提交更改—这是你告诉 Git 你的工作进展的方式。
Conclusion
最后，请查看我们团队在过去几年完成的这份开放项目列表。每个项目都有两个指标：代码行数和代码点击数。有趣的是，相对较小的项目却有非常大的（超过一百万）点击数。这立即让我想起我们在其中投入了多少时间以及它们的年龄。
我在这个分析中使用了HoC指标：每行代码你支付多少钱？那篇文章比较了一个传统项目，每个HoC支付$3.98，和一个由Zerocracy管理的开源项目，每个HoC支付¢13。
我的结论是，这个代码行数指标可以作为软件开发项目中的进度跟踪工具使用。此外，它可以用于团队规模、项目预算、开发进度等方面的估算。显然，代码行数不能是唯一的指标，但与其他指标结合使用可以在估算、规划和跟踪方面提供很大帮助。
PS. 请尝试hitsofcode.com。
Translated by ChatGPT gpt-3.5-turbo/35 on 2023-09-09 at 05:09
