在本文中，作者分析了花费在编写书籍或程序代码上的时间，并得出了一种有趣的模式。 它可用于安排项目工作。霍夫施塔特定律：即使考虑霍夫施塔特定律，任何业务的持续时间总是比预期的长。
-道格拉斯·霍夫斯塔特， 哥德尔，阿舍尔，巴赫
撰写散文和代码有很多共同点。 但是最明显的相似之处可能是作家和程序员都无法准时完成工作。 作家因逾期而臭名昭著。 程序员赢得了人们的声誉，他们的结果总是与最初的计算大相径庭。 问题出现了：为什么？
今天，我有了一个解决办法。 我的发现令我惊讶。
学习我的书
我的两本书，《
Hello》，《 Startup》和《
Terraform：我们启动并工作》 ，都是我在
Atlas图书创建环境中编写的，该环境可使用Git管理所有内容。 这意味着每行文本，每一次编辑和每一次更改都已提交到Git提交日志。
让我们检查一下写两本书花了多少精力。
嗨启动让我们从我的第一本书开始。 它有602页，大约19万个单词。 我在
Hello，Startup git存储库中运行了
cloc ，并得到以下结果
（为简单起见，小数部分将被丢弃）：
602页包含26,571行文本。 大部分股份都是用
AsciiDoc编写的，类似于Markdown。 Atlas使用它来编写几乎所有内容。 Atlas使用HTML和CSS定义了一本书的布局和结构。 除了它们，还有其他编程语言（不仅限于Java，Ruby，Python），其中针对本书中讨论的主题编写了各种示例。
但是602页和26,571行只是最终结果。 它们并不能反映大约10个月的写作，更改，编辑，校对，风格调整，研究，注释和其他有助于本书出版的工作。 因此，为了获得更多有用的想法，我使用了
git-quick-stats来分析整本书的提交日志。
因此，我增加了163,756行，并删除了131,425行，总共得到295,181行处理的材料。 也就是说，事实证明，我总共写入或删除了295181行，结果剩下26571行。 该比率略高于10：1。 为了获得每一行，我必须先写另外十行！
我承认，对添加到Git和从Git删除的行数进行计数不能被认为是编辑过程的理想指标。 但是，至少，这使我们能够理解，简单的计算不足以评估完成的工作。 这个过程的很大一部分根本没有反映在Git提交日志中。 例如，在我搬到Atlas之前，前几章是用Google文档编写的，对计算机的许多编辑都没有提交。
尽管这些数据远非理想，但我认为“原始文本材料”与已出版出版物的总体比例为10：1。
Terraform：我们开始工作让我们检查一下这个比例是否适用于我的第二本书《
Terraform：我们启动并工作》 ，它包含206页和大约52,000个单词。
cloc的简化输出：
206页包含8410行文本。 再说一次，尽管本书包含大量的代码示例，这些代码示例主要是用Terrain的主要语言HCL编写的，但是大多数文本还是用AsciiDoc编写的。 除了他，我还使用许多Markdowns来记录HCL示例。
我们将使用
git-quick-stats来检查本书的修订历史：
在将近五个月的时间里，我增加了32,209行，并删除了22,402行，总共回收了54,611行。 评估该书的编辑过程的准确性受到的影响更大，因为该工作始于
一系列博客文章 ，在移交给Atlas和Git之前经过了切实的修订。 这些博客文章的数量至少占本书的一半，因此将已处理文本的最终比率提高50％是合乎逻辑的。 也就是说，结果是54611 * 1.5 = 81 916行可编辑的文本，总共8410行。
再一次，比率约为10：1！
作家没有按时完成也就不足为奇了。 如果时间表应交付一本250页的书，那么实际上，事实证明，在此过程中，我们将写2500页。
那编程呢？
进展如何？ 我决定检查几个成熟度不同的开源git存储库：从几个月到23年。
terraform-aws-couchbase（2018）terraform-aws-couchbase是一组用于在AWS上部署和管理Couchbase的模块，其源代码于2018年开放。
cloc的简化输出：
这是检查
git-quick-stats ：
我们得到多达37693行的工作代码，从而以5：1的比率生成了7481行最终代码。 即使在不足5个月的存储库中，我也不得不重写每行五次！ 评估软件开发非常复杂也就不足为奇了：我们甚至没有想到，要获得7.5万行最终代码，我们实际上必须编写3.5万行
让我们看看旧产品的情况如何。
Terratest（2016）Terratest是一个于2016年创建的开源库，用于测试基础架构代码。
cloc的简化输出：
git-quick-stats的结果：
这是49 126个工作代码行，这些代码最终变成了6140行。 对于一个两年的存储库，比率为8：1。 但是Terratest还很年轻，所以让我们看一下旧的存储库。
地形（2014）Terraform是2014年创建的开源库，用于使用编程方法管理基础结构。
cloc的简化输出：
git-quick-stats的结果：
我们获得12,945,966行代码，最终结果为1,371,718行。 9：1的比例。 Terraform已经存在了将近4年，但是该库尚未发布，因此即使达到这个比例，其代码库仍无法被称为成熟的。 让我们进一步回顾过去。
Express.js（2010年）Express是一种流行的开源JavaScript框架，于2010年发布，用于网络开发。
cloc的简化输出：
git-quick-stats的结果：
我们得到224211个工作行的代码，减少到15325个最后一行。 结果14：1。 Express已有8年的历史，其最新版本为4.x。 它被认为是Node.js上最受欢迎和经过考验的Web框架。
似乎只要比率达到10：1的水平，我们就可以自信地说代码库已经“成熟”。 让我们检查一下如果您更深入地了解过去会发生什么。
jQuery（2006）jQuery是2006年发行的流行的开源JavaScript库。
cloc的简化输出：
git-quick-stats的结果：
总共730,146行代码，最终结果为47,559行。 对于将近十二年的存储库，比例为15：1。
再走十年吧。
MySQL（1995年）MySQL是1995年创建的流行的开源关系数据库。
cloc的简化输出：
git-quick-stats的结果：
对于将近23年的存储库，我们获得58 562 999条工作行，最终代码3 662 869行以及16：1的比率。 哇！ 每行MySQL代码已被重写16次。
结论
我的书的广义结果如下：
职称
| 工作线
| 摘要行
| 比例
|
嗨启动
| 295181
| 26,571
| 11：1
|
Terraform：我们开始工作
| 81916
| 8410
| 10：1
|
这是各种编程项目的摘要表：
职称
| 制造年份
| 工作线
| 摘要行
| 比例
|
terraform-aws-couchbase
| 2018年
| 37,693
| 7481
| 5：1
|
Terratest
| 2016年
| 49126
| 6140
| 8：1
|
地貌
| 2014年
| 12945966
| 1371718
| 9：1
|
快车
| 2010
| 224211
| 15325
| 14：1
|
jQuery的
| 2006年
| 730,146
| 47559
| 15：1
|
的MySQL
| 1995年
| 58562999
| 3662869
| 16：1
|
所有这些数字是什么意思？
规则10：散文与程序设计中的1鉴于我的数据集有限，我只能得出一些初步结论：
- 该书的“原料”与“最终产品”的比例约为10：1。 与编辑者讨论提交材料的时间表时，请记住这一点。 如果您需要写一本300页的书，那么实际上您必须撰写约3000页。
- 对于成熟且不平凡的软件，可以推导出类似的规则：处理后的代码量与总数之比至少为10：1。 当经理或客户要求您估算时间成本时，请记住这一点。 一万行的应用程序将需要您编写约十万行。
这些发现可以概括
为编写和编程的
10：1规则 ：
编写好的软件或文本要求平均每行被重写10次。
后续步骤
当然，不能将代码行和文本行视为理想的措施。 但是，我相信，如果您收集了足够的数据，则可以确定10：1规则是否通用并且对确定完成项目的截止日期有用。
我想得到答案的一些问题：
- 是否可以将处理后的代码行与最终代码行的比率用作评估特定软件成熟度的快速指标？ 例如，如果对数据库，编程语言或操作系统的比率达到至少10：1，我们是否可以信任关键基础结构问题的解决方案？
- 工作文本的数量是否取决于软件类型？ 例如，比尔·斯科特（Bill Scott）发现，在Netflix中，只有大约10％的用户界面代码可以使用一年 ，而此时剩下的90％都可以完全重写。 后端，数据库，命令行实用程序和其他类型程序的代码替换速度是多少？
- 初始发行后将处理百分之几的代码？ 也就是说，可以将百分之几的工作视为“软件支持”？
如果您是书籍的作者，并且可以进行类似的分析，那么我将很高兴知道您的结果。 而且，如果有人有时间使这种分析自动化，那么了解各种开放源代码项目中的关系将非常有用。
8月13日更新关于
Hacker News和
Reddit的r / programming的帖子的讨论揭示了另外两个有趣的观点：
- 显然， 电影 ，新闻，音乐和摄影也适用类似的10：1规则！ 谁会想到的？
- 读者留下了很多评论，即使在Git中更改一个字符也可以算作插入或删除行，因此10万行更改的指示符并不意味着每行都经过了处理。
最后一句话是正确的，但是，正如我在上面所写，我的数据没有考虑其他类型的更改：
- 我不会为每行单独提交。 我可以更改十次，但只能提交一次。
- 上一段中描述的情况与编程更加相关。 在代码测试过程中，我只能更改一行50次，而一次提交一次。
- 在Git之外完成了许多编辑和编写周期（某些章节以Google Docs或Medium编写，而样式编辑以PDF进行）。
我认为所有这些因素都弥补了Git中插入或删除行的特殊性。 当然，我的估算可能不准确，实际比例为8：1或12：1。 但总的来说，两者之间的差异并不是很大，而且10：1更容易记住。
8月14日更新Github
Decagon使用bash脚本创建了一个名为
hofs-churn的存储库，以轻松计算已在存储库中编写
了多少代码。 他还使用它来分析许多存储库，例如React.js，Vue，Angular，RxJava和许多其他存储库，结果非常有趣。
