神话般的人每月每个开发人员每天10行-大型项目有多近？[关闭]

大家总是说他们可以击败“神话般的男人月”中的“每个开发人员每天10条线”，而开始一个项目，我通常一天可以得到几百条线。

但是在我以前的雇主那里，所有的开发人员都很敏锐，但这是一个大型项目，超过一百万行代码，具有非常繁琐的认证要求，并且与其他数百万行的项目接口。在某些时候，出于好奇心的考虑，我在小组中的运输产品中绘制了代码行（不算我们开发的工具），而且可以肯定的是，逐步增加，每个开发人员每天净增加约12行。不计算变更，测试代码或开发人员并非每天都在处理实际项目代码的事实。

别人好吗？您面临什么样的要求（我想这是一个因素）？

我认为添加的行数在很大程度上取决于项目的状态，添加到新项目的速度将比开始项目的速度高得多。

两者之间的工作是不同的-在大型项目中，您通常会花费大部分时间来确定零件之间的关系，而实际上只花费很少的时间来更改/添加零件。而在一个新项目中-您通常会写...直到它足够大并且速度降低。

在我目前的项目之一中，在某些模块中，我为代码库贡献了负的行数而感到自豪。识别哪些代码区域变得不必要的复杂性并可以通过更简洁，更清晰的设计进行简化是一项有用的技能。

当然，某些问题本质上是复杂的，需要复杂的解决方案，但是在大多数大型项目中，定义不明确或需求变化的区域往往具有过于复杂的解决方案，每行的问题数量更多。

考虑到要解决的问题，我更喜欢减少行数的解决方案。当然，在小型项目开始时，我每天可以生成十行以上的代码，但是我倾向于不考虑我编写的代码量，仅考虑它的功能和性能。我当然不会打算每天突破十条线，也不认为这样做是一项成就。

我喜欢这句话：

如果我们希望计算代码行，则不应将其视为“产生的行”，而应视为“花费的行”。-Edsger Dijkstra

有时候，您通过删除代码比添加代码做出了更多贡献

您应该停止使用该指标，在大多数情况下，它毫无意义。内聚性，耦合性和复杂性比代码行更重要。

别人好吗？

我是我们公司唯一的全职开发人员，并且在过去7年中编写了50万行OCaml和F＃代码，相当于每天大约200行代码。但是，该代码中的绝大多数是教程示例，其中包含数百个单独的项目，每个项目的长度为几百行。另外，OCaml和F＃之间有很多重复。我们不维护任何大于50kLOC的内部代码库。

除了开发和维护自己的软件外，在过去的7年中，我还为许多行业客户提供了咨询服务。对于第一个客户，我在3个月内写了2,000行OCaml，每天20行代码。对于下一个客户，我们四个人编写了一个编译器，在6个月内生成了数百万行C / C ++ / Python / Java / OCaml代码以及文档，每个开发人员每天有2,000行代码。对于另一个客户，我在6个月内用F＃的6kLOC替换了50kLOC的C ++，即每天-352行代码。对于另一个客户，我正在用F＃重写OCaml的15kLOC，其大小相同，因此每天需要0行代码。

对于我们当前的客户，我将在1年内（通过编写定制的编译器）将160万行C ++和Mathematica代码替换为F＃的160kLOC，这将是每天-6,000行代码。这将是迄今为止我最成功的项目，每年将为我们的客户节省数百万美元的持续费用。我认为每个人的目标应该是每天编写-6,000行代码。

在没有实际检查我的“神话人月”的副本的情况下（每个阅读此书的人都应该确实有现成的副本），布鲁克斯有一章用写的线条来考察生产力。对他来说，有趣的一点不是每天实际写入的行数，而是在汇编程序和PL / I中似乎大致相同的事实（我认为这是所使用的高级语言）。

Brooks并不想抛出某种任意的生产率数字，但他是根据实际项目的数据进行的，据我所知，它们平均每天可能只有12条生产线。

他确实指出，生产力可能会发生变化。他说，编译器的难度是应用程序的三倍，操作系统是编译器的三倍。（他似乎喜欢使用三个乘数来分隔类别。）

我不知道他是否欣赏程序员生产力之间的个体差异（尽管在数量级参数上他确实提出了七个差异），但是众所周知，卓越的生产力不仅仅是编写更多内容的问题代码，还要编写正确的代码来完成这项工作。

还有环境问题。布鲁克斯推测了什么会使开发人员变得更快或更慢。像很多人一样，他质疑当前的风尚（使用分时系统进行交互式调试）是否比旧的方法（使用整台机器进行两小时的拍摄进行仔细的预先计划）更好。

鉴于此，我将无视他提出的任何实际生产力数字，因为这些数字毫无用处；这本书的持续价值在于人们坚持不学习的原则和更普遍的教训。（嘿，如果每个人都学过它们，那本书只会是历史性的，就像弗洛伊德关于存在某种潜意识一样的所有论点一样。）

每天很容易获得几百行代码。但是，每天尝试获取几百行高质量的代码，这并非易事。最重要的是，通过调试并每天进行几乎没有新行或几乎没有新行的日子，平均值将很快下降。我花了数周时间调试一些棘手的问题，答案是1或2行代码。

认识到谈论物理代码行毫无意义，这会更好。物理代码行（LoC）的数量非常依赖于编码样式，以至于一个开发人员到另一开发人员的数量级可能变化一个数量级。

在.NET世界中，有一种方便的方法来计算LoC。顺序点。顺序点是调试的单位，它是放置断点时以深红色突出显示的代码部分。通过序列点，我们可以讨论逻辑LoC，并且可以跨各种.NET语言比较此指标。大多数.NET工具都支持逻辑LoC代码度量标准，包括VisualStudio代码度量标准，NDepend或NCover。

例如，这是一种8 LoC方法（不考虑开始和结束括号的序列点）：

长期生产LoC的时间必须计算在内。有时候，您会吐出200多个LoC，而另一些日子，您甚至要花费8个小时甚至不添加一个LoC就可以修复错误。有时，您将清理无效代码并删除LoC，有时，您将花费所有时间来重构现有代码，而不将任何新的LoC添加到总数中。

就个人而言，仅在以下情况下，我才在自己的生产率得分中计算单个LoC：

1. 它包含在单元测试中
2. 它与某种代码合同相关联（如果可能，合同当然不能检查所有LoC）。

在这种情况下，我过去五年为.NET开发人员编写NDepend工具的个人评分平均每天为80个物理LoC，而丝毫没有牺牲代码质量。这种节奏是持续的，我认为它不会很快消失。总而言之，NDepend是一个C＃代码库，当前的权重约为115K物理LoC。

对于那些讨厌计算LoC的人（我在这里的评论中看到了很多），我证明一旦进行了充分的校准，计算LoC就是一个很好的估算工具。在对在我特定的开发环境中实现的许多功能进行编码和测量之后，我到达了可以精确估计LoC中任何TODO功能的大小以及将其交付生产所花费的时间。

没有银弹这样的东西。

像这样的单个指标本身是没有用的。

例如，我有自己的类库。当前，以下统计是正确的：

总行数：252.682
代码行数：127.323
注释：99.538
空行数：25.821

假设我根本不写任何注释，即127.323行代码。按照您的比例，该代码库将花费我大约10610天的时间。那是29年。

我当然不用花29年的时间来编写该代码，因为它全都是C＃，而且C＃没那么久。

现在，您可以争辩说代码不是很好，因为显然我必须超过您每天12行的指标，是的，我同意这一点，但是如果我将时间线缩短到当1.0发布时（直到2.0发布我才真正开始制作它），也就是2002年2月13日，大约2600天，平均每天48行代码。

所有这些代码行都很好吗？哎呀 但是每天减少到12行代码？

哎呀

一切都取决于。

您可以让顶尖的程序员每天以数千行的数量来编写代码，而中级程序员每天以数百行的数量来编写代码，并且质量是相同的。

是的，会有错误。

您想要的总数就是余额。更改的代码量，发现的错误数量，代码的复杂性以及修复这些错误的难度。

史蒂夫·麦康奈尔（Steve McConnell）在他的《软件估算》一书中给出了一个有趣的统计数据（第62页，表5.2）。他区分了项目类型（航空，商业，电信等）和项目规模10 kLOC，100 kLOC，250 kLOC。在LOC / StaffMonth中为每个组合给出了数字。EG Avionic：200、50、40个Intranet系统（内部）：4000、800、600嵌入式系统：300、70、60

意思是：例如。对于Avionic 250-kLOC项目，有40（LOC /月）/ 22（天/月）== <2LOC /天！

我认为这是从瀑布式开发日开始的，当时项目的实际开发阶段可能只占项目总时间的20％至30％。以总的代码行数除以整个项目时间，您将获得大约10行/天。除以编码期限，您将更接近人们所引用的内容。

我们的代码库约为2.2MLoC，需要大约150个人年的努力。在项目的整个生命周期中，每个开发人员每天大约需要75行c ++或c＃。

我认为项目规模和涉及的开发人员数量是其中的重要因素。我的职业生涯远不止于此，但我一直都是一个人工作，因此与其他程序员一起工作不会有任何损失。

好的计划，好的设计和好的程序员。您会得到所有的信号，并且不会花费30分钟来写一行。是的，所有项目都需要您停止和计划，思考，讨论，测试和调试，但是每个公司每天需要两行，才能让俄罗斯方块工作。

最重要的是，如果您以每小时2条线的速度为我工作，那么最好为我提供很多咖啡和按摩脚，以免被解雇。

有人怀疑当所有的东西都是用C语言编写的sys应用程序时，这种多年生的经理人糖果就被创造出来了，因为如果没有别的，魔幻数字将根据应用程序的语言，规模和性质而变化几个数量级。然后，您必须取消注释和属性。最终谁在乎编写的代码行数？达到1万行时，应该完成吗？100K？如此武断。

这毫无用处。