我在寻找真实的数字和经验，请不要太主观：
在寻找其他东西时，我偶然发现了一个有趣的陈述，部分内容如下：
[...]全国平均水平是每人每年 9,000 行代码。[...]
我写了很多代码，但不是全职的。当我回顾过去一年的项目时，我做了一个（非常）粗略的计算（只计算代码行，没有注释或白线），我在一年中达到了大约 19.000 条，这使它成为一个项目。如果我可以自动化其中的一部分，我可以在时间和金钱上扣除利润。
为了估计大型项目的时间节省，我需要平均值。在 C#（或其他选择的语言）中，人类平均一年编写多少行代码？而且，看看你自己的情况，你是否认为你的手写代码可以（部分地）自动化并且有什么好处？
18000 平均每天大约 36 行代码。
每天只有 36 行代码，有什么问题？问题是调试和重写你的代码。
自动化编码的任何事情都不会加快你的速度——事实上，任何你可以自动化的东西都可能不应该被编码，因为如果你在代码中自动输入某些模式，它应该被排除在外。
您可以节省时间的地方是更加小心您的编码方式。让您的项目更快地通过 QA——使用更明确、类型安全的语言和更清晰的代码编写代码。
尽可能使您的代码数据驱动并充分考虑因素，尽管它会减少您交付的 LOC，但它会使每个人的生活更轻松，项目交付速度更快。
永远不要自动输入代码——如果可以，那你就错了！
另一种思考方式——您创建的每一行代码都必须进行调试和维护。当您可以创建完全分解的代码时，您为什么还要想办法给每个人更多的工作（完全分解的代码的输入不能自动化——几乎按照定义）。
首先，编写的代码行与实际生产力的相关性不高。至少在我看来，如果你想衡量和/或估计生产力，功能点是更有效的衡量标准。其次，当一个指标在很大范围内变化时，平均值通常意义不大。在这种情况下，几何平均值通常比算术平均值意味着更多，但（至少）没有关于方差/标准偏差的东西，它仍然没有多大意义。
我还要注意，有一些相当复杂的模型已经过大量研究，甚至针对实际项目进行了测量，以至少了解它们的结果与现实相关。例如，COCOMO II模型通常会产生比每单位时间仅使用代码行数更好的结果。至少有一个免费的在线实现（编辑：看看它，这现在允许基于 LoC 或基于功能点的建模）。还有一个工具，如SoftStar和Function Point Modeler）将类似 COCOMO 的模型与功能点结合起来，以获得（至少对我而言）看起来相当可靠的结果。
这是神话人物月中讨论的指标类型。以人日/月/年为单位估算项目，或将代码行数作为生产力指标来保证报告的不准确性。
我相信 LOC 的费率很大程度上取决于项目中的技术债务。
我有一个 27KLOC 的项目（SQL）（加上 4K 更多的支持）。处理这段代码，超过 7 个月，我在项目中添加了 3K 净新 LOC，其中大约 14KLOC 仅用于一次性测试（测试以隔离异常，而不是单元测试）。
根据您的测量方式，我写了 29KLOC/年 ((3K+14K)/7months*12months) 但只产生 5KLOC/year (3K/7months*12months)。
将代码 (27KLOC) 视为债务，我们的代码每月生成 7% (2KLOC) 的一次性代码，或每年生成 88% (24KLOC)。
假设我可以继续产出整整 29KLOC/年，并且假设维护代码的成本保持在 88%/年，我个人的项目限制是 33K 行代码。除此之外，我将把所有时间都花在支付技术债务的利息上，编写一次性代码，并产生净零 LOC。
幸运的是，最后一次 3KLOC 是一次重构，这应该会降低我的利率。