C＃开发人员每月可以生产多少行代码？[关闭]

我工作场所的一位高管向我和开发人员小组提问：

C＃开发人员每月可以生产多少行代码？

一个旧的系统将被移植到C＃中，他希望此措施成为项目计划的一部分。

从某些（显然是可信的）消息来源，他得到的答案是“ 每月 10 SLOC ”，但他对此并不满意。

该小组同意这几乎是不可能的，因为这取决于一长串情况。但是我们可以断定，如果我们没有给出更适合他的答案，那个人就不会离开（或者对我们非常失望）。因此他留下了更好的答案：“ 每天 10 SLOC ”

这个问题可以回答吗？（立即使用，甚至进行一些分析）

询问您的主管，他的律师每月可以写多少页合同。然后（希望）他将意识到写单页合同和写300页合同而没有漏洞和矛盾之间存在巨大差异。或者在编写新合同和更改现有合同之间。或者在撰写新合同并将其翻译成其他语言之间。或改为不同的法律制度。也许他甚至会同意“每单位时间的合同页数”不是衡量律师生产率的好方法。

但是给您一个真正的问题的答案：以我的经验，对于一个新项目，每天数百个SLOC和开发人员并不少见。但是，一旦出现第一个错误，这个数字就会急剧下降。

C＃开发人员每月可以生产多少行代码？

如果它们很好，则小于零。

用另一种方式运行...现在。

LoC是您可以使用的最差的指标之一。

糟糕的开发人员每天可能会比优秀的开发人员编写更多的LoC，但会产生垃圾代码。

取决于代码的复杂性，可以通过自动化过程来完成移植，这将导致每天发生成千上万的LoC更改，而语言结构完全不同的更困难的部分则每天被移植到100LoC。

送他阅读SLOC上的Wikipedia页面。If提供了一些很好而简单的示例来说明为什么它是如此差劲。

正确答案：不...

该主管应受过教育，认为SLOC不是分析进度的有效指标

马虎的答案：任何数字都可以组成。

只需给他一些电话号码，您和您的团队就可以轻松地增加这个电话号码。（通过放行，除非行，空行，评论等，否则只是为了允许这个家伙继续生活在他的幻想世界中，并困扰另一个团队并继续痛苦的循环，这使thedailywtf有了一个故事。

不好，但是可行。

乍一看，这个问题看起来绝对是愚蠢的，这里的每个人都只回答了愚蠢的C＃LoC部分。但是有一个重要的细微差别-这是有关移植性能的问题。提出此问题的正确方法是询问开发人员在给定的时间内可以处理多少行源项目的代码（正在移植的代码）。这是一个完全合理的问题，因为代码行的总数是已知的，而这恰恰是要完成的工作量。解决此问题的正确方法是收集一些历史数据-例如工作一周，并评估每个开发人员的性能。

我只有一件事要说：

“通过代码行来衡量编程进度就像通过重量来衡量飞机制造进度。”

- 比尔盖茨

之后，您可能会说比尔·盖茨不知道如何制作成功的软件;）

注意：不过，SLOC是衡量代码库复杂性的很好方法！

I 
can
write
large
numbers
of
lines
of
code
per
month.

实际上，单词的数量成正比。

你明白我的意思吗？

我对此可能会有稍微不同的立场，但是我想我可能理解为什么如果高管人员当前正在进行项目规划，他们为什么要寻找这些信息。由于很难估计一个项目要花费多长时间，因此使用的一种方法（请参阅：软件估计：揭开妖术的神秘面纱）是根据项目的数量来估计需要多长时间。类似项目中的SLOC，现在开发商可能平均生产。在实践中，这是要使用小组手头上具有相同或相似开发人员的类似项目的历史记录来完成的。

但是，这些估算仅用于基本的项目计划，而实际上并不旨在设定开发人员在项目上的步调，这是毫无价值的，因为事情每天都在变化。因此，您将SLOC用作估算工具时所读到的大部分内容是，从长远来看，如果您已经拥有丰富的知识，则它们会很好，但是对于日常使用而言却很糟糕。

通常称呼你的老板是个白痴是个坏主意，所以我的建议从理解和讨论指标开始，而不是拒绝它们。

一些实际上不被认为是白痴的人使用了基于代码行的指标。Fred Brooks，Barry Boehm，Capers Jones，Watts Humphries，Michael Fagan和Steve McConnell都使用了它们。即使您只是想和一位同事说，您可能已经使用了它们，这个上帝模块是4000行，需要分成更小的类。

我们中许多人都尊重来自这个问题的具体数据。

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

我怀疑每个程序员小时的代码行的最佳用途是表明，在项目的整个生命周期中，这个值会很高，但是随着发现并修复缺陷，将添加新的代码行来解决那些并非原始估算的一部分，因此删除代码行以消除重复并提高效率将显示LOC / hr表示生产力以外的其他信息。

• 如果快速，草率，肿地编写代码，并且不进行任何重构尝试，则视在效率将达到最高。这里的道义是，您必须谨慎对待自己测量的内容。
• 对于特定的开发人员而言，如果他们本周要添加或修改大量代码，那么下周在代码审查，测试，调试和返工方面可能要付出技术上的债务。
• 一些开发人员将以比其他开发人员更稳定的产出率工作。可以发现，他们花费最多的时间来获取良好的用户故事，非常快速地转向并进行相应的单元测试，然后转向并快速生成仅专注于用户故事的代码。这里的收获是，有条不紊的开发人员可能会快速周转，编写紧凑的代码并减少返工，因为他们在开始编写代码之前就非常了解问题和解决方案。减少代码的数量似乎是合理的，因为它们仅在经过深思熟虑之后才进行编码，而不是之前和之后进行编码。
• 当评估代码的缺陷密度时，会发现它不均匀。一些代码将解决大多数麻烦和缺陷。它将是重写的候选人。发生这种情况时，它将成为最昂贵的代码，因为它具有高度的返工率。它具有最高的总代码行数（可以通过CVS或SVN之类的工具报告，添加，删除，修改的总行数），但每小时投资的净代码行数最低。这最终可能是实现最复杂问题或最复杂解决方案的代码的组合。

无论如何在代码行中对程序员的生产力进行辩论，结果都会发现，您需要的人力资源超出了您的承受能力，而且该系统永远无法及时完成。您真正的工具不是指标。他们使用的是卓越的方法论，可以雇用或培训的最佳开发人员以及对范围和风险的控制（可能是敏捷方法）。

给他一个更好的衡量标准

取而代之的LOC，解释这是在使用最坏的度量。然后给他一个替代方案：

功能号/功能每特性/功能要求- > NOFF / RFF

您可能需要在NOFF / RFF的基础上增加权重/标准化，以适应每周的请求量。

:)显然以上内容已构成，但任何方面都比SLOC更好...

我可以告诉你，一个大型项目的承包人一年写了15000 LOC。这是一个令人难以置信的粗略答案，但对我们来说却很有用，因为我们现有40万个C ++ LoC，并且我们可以发现，将其全部转换为C＃大约需要26个工年。给予或接受。

因此，现在我们知道了大概的数量级，我们可以为它做更好的计划-聘请20个开发人员并为他们估算一年的工作量是正确的。在计算之前，我们不知道迁移需要多长时间。

因此，我的建议是在特定的时间内检出您编写的所有代码（我很幸运有一个新的项目可以处理），然后在其上运行众多代码度量工具之一。用时间除以数字，您可以给他一个准确的答案- 您每天实际写多少LOC 。对于我们来说，每天的成本为90 LOC！我想我们确实有很多关于该项目的会议和文档，但是我想我们在下一个会议上也会有很多会议和文档:)

听起来很正确。

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

如果考虑到调试，文档编制，计划等，则平均每天大约需要10行代码。实际上，我每天会评价10条线（例如，非常有生产力的开发人员）。

即使您一天可以完成几百行（这是不可持续的）。在您添加了所有单元测试文档之后，当然还不是质量代码，当然，在单元测试显示错误之后，还要调试代码。完成所有操作后，您将回到10。

我的猜测是，使用C＃这样的语言进行开发的开发人员应该每天能够编写/生成大约1万笔LoC。我想，我可以做到。我永远也不会。

您想要开发人员的是，每天可以在10个LoC中完成工作。更少的代码总是更好。我经常会开始生成大量代码，然后删除代码，直到达到最大程度的简单性为止，因此实际上我确实遇到了负面的LoC。

从某种意义上说，编码就像诗歌。问题不是，诗人可以写几行诗，而是十四行诗中他能写多少诗。

让您的经理来处理它，或开始找工作。

认真地说，您可能会花些时间，最终可能无法向执行人员说明衡量项目完成进度的正确和不正确的方法。但是，在所有现实中，工程和项目经理的作用是什么。

另一方面，这种情况使得问题执行人员就是您的工程和/或项目经理。您有更大，更基本的问题要处理，即使它们尚未展现出来。在这种情况下，这样的问题可以作为“警告镜头”，以解决更大的问题。

其他答案是正确的，这是一个愚蠢的问题，答案并不意味着该死的事情。没错，但是我碰巧知道大约一个月内我生产了多少行代码。

没有XML-doc，大约有3000行C＃代码。我正在实施新功能，最终在一个月或一个月零一个星期内得到了这个金额。所有这些最终都由源代码控制完成，编写了许多代码，然后重构或删除了它们。

我是C＃开发人员，我想尽力而为，但是我不能告诉你我客观上的出色。我试图编写出色的代码，并付出了很多努力以使其易于维护。我在这段代码中只发表了一次或两次注释。

我不知道这是太多还是太少的代码行，我不得不说我不在乎。这是毫无意义的数据，不能以任何方式安全地用于推断。但是我碰巧知道这些数据，所以我决定分享。

好吧，我像往常一样参加这个聚会有点晚，但这实际上是一个有趣的聚会。最初，我和大多数人都以为高管的问题是愚蠢的。但是，我阅读了SK-logic的答案，才意识到这是一个无意义的问题。或者换句话说，问题背后有一个有效的问题。

经理经常需要尝试确定项目的可行性，资金，人员配备等。这是一个明智的问题。对于Straightford端口，基于端口代码行的估计值除以每个开发人员每天的估计平均代码行数得出的结果很简单，但是由于本页上给出的所有原因，注定要失败。

一个更明智的方法是：-

1. 对于现场估算，请对代码有最丰富经验的开发人员估算所需的时间。由于许多原因，我肯定不会这样做，这是不正确的，但是一开始他们最好能够做到。至少他们应该知道，即使有额外的资源，在一周或几年后是否容易做到。如果有任何类似大小的端口或完成的工作，他们可以以此为指导。
2. 估计组件的端口以获取总大小。需要包括与端口不直接相关的任务，例如设置基础结构（机器，构建系统等），调查和购买软件等。
3. 确定端口中风险最高的组件，然后从这些组件开始。这些可能会使估计数字最大程度地被炸毁，因此应尽可能提前进行，以免港口后期出现意外情况。
4. 根据步骤2中的规模跟踪进度，以连续计算端口的预期持续时间。随着项目的进行，这应该变得更加准确。当然，已经移植的代码行数（原始代码库中的功能现在已在移植的代码中）也可以用作度量标准，并且实际上有助于确保移植原始产品而不是移植产品。在不处理实际端口的情况下添加了许多很酷的新功能。

这些只是最基本的步骤，当然还有很多其他相关活动，例如调查移植工具和可插拔框架，创建原型，确定真正需要移植的内容，重用测试工具和基础结构等。