神话人月每个开发人员日10行-大型项目有多接近？

你应该停止使用这个度量标准，它在大多数情况下是没有意义的。内聚性、耦合性和复杂性是比代码行更重要的度量标准。

每天获得几百行代码很容易。但是每天尝试获得几百行高质量的代码并不容易。除此之外，还要进行调试，每天只有很少或根本没有新行，这样平均值很快就会下降。我花了几个星期调试难题，答案是1到2行代码。

人们怀疑这种长期存在的“经理糖果”是在所有东西都是用 C 语言编写的 sys 应用程序时创造出来的，因为如果没有其他原因的话，这个神奇的数字会随着应用程序的语言、规模和性质的不同而有所数量级。然后您必须对注释和属性进行折扣。最终，谁会在乎编写的代码行数呢？当你达到10K 线时，你就应该完成了吗？十万？太武断了。

没用的。

在我当前的一个项目中，在一些模块中，我很自豪地为代码库贡献了一个负的行数。确定哪些代码区域增加了 没必要的复杂性，并且可以通过更清晰的设计进行简化，这是一项有用的技能。

当然，有些问题本身就很复杂，需要复杂的解决方案，但是在大多数大型项目领域，如果没有很好地定义或改变需求，往往会有过于复杂的解决方案，每一行的问题数量更多。

对于需要解决的问题，我更喜欢减少行数的解决方案。当然，在小型项目的开始阶段，我每天可以生成十多行代码，但我往往不会考虑我写了多少代码，而只考虑它做了什么以及做得如何。我当然不会打算每天打破10行，也不会认为这样做是一种成就。

根本没有银弹这种东西。

这样一个单一的度量标准本身是无用的。

例如，我有自己的类库。目前，以下统计数据是正确的:

总投资额: 252.682
代号: 127.323
评论: 99.538
空白行: 25.821

假设我根本不写任何注释，也就是说，127.323行代码。按照你的比例，那个代码库需要我大约10610天的时间来编写。29年了。

我肯定没有花费29年的时间来编写那些代码，因为它们都是 C # ，而 C # 也没有存在那么长时间。

现在，你可以争辩说代码并不是那么好，因为显然我已经超过了你的每天12行的标准，是的，我同意这一点，但是如果我要把时间表降低到1.0发布的时候(实际上直到2.0发布我才开始做它) ，也就是2002.02-13，大约2600天，平均每天48行代码。

所有这些代码行都是好的吗? 当然不是。但是一天只有12行代码？

当然没有。

看情况。

你可以让一个顶尖的程序员每天大量生产数千行的代码，让一个中等水平的程序员每天大量生产数百行的代码，质量是一样的。

是的，会有虫子。

你想要的总数是余额。代码变更的数量，相对于发现的 bug 数量，相对于代码的复杂性，相对于修复这些 bug 的困难程度。

没有真正检查我的“人月神话”的副本(每个读这本书的人都应该有一个现成的副本) ，有一章布鲁克斯通过写的行来看效率。对他来说，有趣的地方不在于每天实际写的代码行数，而在于它在汇编语言和 PL/I 语言中似乎大致相同(我认为这是使用的高级语言)。

布鲁克斯并不打算抛出某种武断的生产率数据，但他是根据实际项目的数据来工作的，我所能记得的是，平均每天可能有12行数据。

他的确指出，生产率可能会有所不同。他说，编译器的难度是应用程序的三倍，操作系统的难度是编译器的三倍。(他似乎喜欢用三倍乘数来分类。)

我不知道他是否意识到了程序员生产力之间的个体差异(尽管在一个数量级的论证中，他假设了7个因素的差异) ，但是我们知道，高效率不仅仅是写更多的代码，而且还要写出正确的代码来完成工作。

还有环境问题。布鲁克斯推测了一下什么会让开发人员更快或更慢。像许多人一样，他质疑当前的流行(使用分时系统的交互式调试)是否比旧的方式(仔细预先计划用整台机器拍摄两个小时的镜头)更好。

考虑到这一点，我会忽略他提出的任何实际生产率数字，认为它毫无用处; 这本书的持续价值在于人们坚持不学习的原则和更普遍的经验教训。(嘿，如果每个人都学会了，这本书就只有历史意义了，就像弗洛伊德所有关于潜意识存在的论点一样。)

我认为添加的行数很大程度上取决于项目的状态，添加到新项目的速度将远远高于启动项目的速度。

两者之间的工作是不同的-在一个大型项目中，你通常花费大部分时间来确定各部分之间的关系，只有少量的时间用于实际的更改/添加。然而在一个新的项目中，你大多数时候是写作，直到它足够大，速度降低。

我认为这来自于 瀑布发展计划时期，在这个时期，一个项目的实际开发阶段可能只占整个项目时间的20-30% 。取代码的总行数，除以整个项目时间，您将得到大约10行/天。除以编码周期，你就会更接近人们所引用的内容。

我认为项目的规模和参与的开发人员的数量是很大的因素。在我的职业生涯中，我远不止这些，但是我一直都是独自工作，所以和其他程序员一起工作没有什么损失。

Steve McConnell 在他的书“软件评估”(p62表5.2)中给出了一个有趣的统计数据 他区分项目类型(航空电子、商业、 Telco 等)和项目规模10kLOC、100kLOC、250kLOC。这些数字是在 LOC/StaffMonth 中给出的。 脑电图。 航空电子: 200,50,40 内联网系统(内部) : 4000,800,600 嵌入式系统: 300,70,60

也就是说: 例如，对于 Avionic 250-kLOC 项目，有40(LOC/Month)/22(Days/Month) = = < 2LOC/day！

良好的计划，良好的设计和优秀的程序员。你把这些都集中在一起，你不会花30分钟写一行。 是的，所有的项目都需要你停下来计划、思考、讨论、测试和调试，但是每个公司每天都需要两条线路才能让俄罗斯方块运行起来。

总之，如果你为我工作，每小时两条线，你最好给我买很多咖啡，按摩我的脚，这样你就不会被炒鱿鱼了。

我喜欢这句话:

如果我们希望计算代码行数，我们不应该把它们看作“生成的行”，而应该看作“花费的行”。 - 是的

有时，通过删除代码而不是添加代码，可以做出更多的贡献

我们的代码库大约是2.2 MLoC，耗时约150人年。这使得在项目的整个生命周期中，每个开发人员每天的 c + + 或 c # 代码大约是 75行。

最好是认识到讨论代码的物理行是毫无意义的。物理代码行(loC)的数量是如此依赖于编码风格，以至于在不同的开发者之间数量级会有所不同。

在。NET 世界中有一种方便的方法来计算 LoC。序列点.序列点是一个调试单元，它是放置断点时用深红色突出显示的代码部分。通过序列点，我们可以讨论 逻辑逻辑控制，并且这个度量可以跨不同的。NET 语言。大多数人都支持逻辑 LoC 代码度量。NET 工具，包括 VisualStudio 代码度量、 NDepend 或 NCover。

例如，这里有一个8 LoC 方法(不考虑开始和结束括号序列点) :

土地承包经营权的生产必须长期计算。有些日子你会吐出超过200个 LoC，有些日子你会花8个小时修复一个 bug，甚至没有添加一个单一的 LoC。有时候你会清理死代码，移除 LoC，有时候你会花费所有的时间重构现有的代码，而不是添加任何新的 LoC 到总数中。

就我个人而言，我只有在下列情况下才会在自己的工作效率得分中计入一个 LoC:

1. 它由单元测试覆盖
2. 它与某种代码契约相关联(如果可能的话，当然不是所有的 LoC 都可以通过契约检查)。

在这种情况下，我的个人成绩在过去5年编码的 NDepend 工具为。NET 开发人员的平均值是 在不牺牲代码质量的情况下，每天80个物理 LoC。这种节奏是持续的，我不认为它会很快减弱。总而言之，NDepend 是一个 C # 代码库，目前重量约为115K 物理 LoC

对于那些讨厌计算 LoC 的人(我在这里的评论中看到了很多) ，我证明了 一旦充分校准，计数 LoC 是一个很好的估计工具。在编写并测量了在我特定的开发环境中实现的几十个特性之后，我达到了一个点，我可以精确地估计 LoC 中任何 TODO 特性的大小，以及将其交付到生产环境所需的时间。

其他人怎么样？

我是 我们的公司唯一的全职开发人员，在过去的7年里写了50万行 OCaml 和 F # 代码，相当于每天写200行代码。但是，绝大多数代码都是教程示例，由数百个独立的项目组成，每个项目只有几百行代码。另外，OCaml 和 F # 之间存在大量的重复。我们不会维护任何大于50kLOC 的内部代码库。

除了开发和维护我们自己的软件之外，在过去的7年里，我还为业界的许多客户提供咨询服务。对于 第一个客户，我在3个月内写了2000行 OCaml 代码，也就是每天写20行代码。对于 下一个客户，我们四个人编写了一个编译器，在6个月内生成了数百万行 C/C + +/Python/Java/OCaml 代码以及文档，每个开发人员每天生成2000行代码。对于另一个客户，我在6个月内将50kLOC 的 C + + 替换为6kLOC 的 F # ，这相当于每天 -352行代码。对于 又一个客户，我正在用 F # 重写15kLOC 的 OCaml，它们的大小相同，所以每天0行代码。

对于 我们现在的客户，我将在一年内用 ~ 160kLOC 的 F # 代替1600000行 C + + 和 Mathematica 代码(通过编写定制编译器) ，这将是每天 -6000行代码。这将是我迄今为止最成功的项目，将为我们的客户每年节省数百万美元的持续成本。我认为每个人的目标应该是每天写 -6,000行代码。