每个人总是说他们可以从“神话人月”中击败“每个开发者每天10行”,并开始一个项目,我通常可以在一天内获得几百行。
但在我以前的雇主中,所有开发人员都非常敏锐,但这是一个大型项目,超过一百万行代码,具有非常繁重的认证要求,并与其他数百万行项目接口。在某些时候,作为一种好奇心的练习,我在我的小组中的运输产品中绘制了代码行(不包括我们开发的工具),当然,逐步地,每个开发人员每天增加大约12行净添加。不计入变更,测试代码或开发人员每天都没有处理实际项目代码的事实。
其他人怎么样?你面临什么样的要求(我想象它是一个因素)?
答案 0 :(得分:108)
在我目前的一个项目中,在某些模块中,我很自豪地为代码库贡献了负数。确定哪些代码区域已经增长不必要的复杂性,并且可以通过更清晰,更清晰的设计进行简化,这是一项非常有用的技能。
当然,有些问题本质上很复杂,需要复杂的解决方案,但在大多数大型项目中,需求定义不明确或需求变化较大的区域往往会出现过于复杂的解决方案,每行的问题数量较多。
考虑到要解决的问题,我更喜欢减少行数的解决方案。当然,在小项目开始的时候,我每天可以生成十多行代码,但我不会想到我编写的代码量,只考虑它的功能以及执行的程度。我当然不会打算每天打十行,或者认为这是一项成就。
答案 1 :(得分:55)
我喜欢这句话:
如果我们希望计算代码行数,我们不应将它们视为“生成的行”,而应视为“行花费”。 - Edsger Dijkstra
有些时候,您通过删除代码而不是添加
来贡献更多答案 2 :(得分:46)
我认为添加的行数在很大程度上取决于项目的状态,添加到新项目的速度将远高于启动项目的速度。
两者之间的工作是不同的 - 在一个大型项目中,您通常会花费大部分时间来确定各个部分之间的关系,而只需要少量实际更改/添加。而在一个新项目中 - 你主要是写......直到它足够大并且速度降低。
答案 3 :(得分:30)
你应该停止使用这个指标,它在大多数情况下都没有意义。内聚,耦合和复杂性是比代码行更重要的指标。
答案 4 :(得分:28)
其他人怎么样?
我是our company唯一的全职开发人员,在过去的7年中编写了500,000行OCaml和F#代码,相当于每天约200行代码。但是,绝大多数代码都是由数百个单独项目组成的教程示例,每个项目都有几百行。此外,OCaml和F#之间存在很多重复。我们没有维护任何大于50kLOC的内部代码库。
除了开发和维护我们自己的软件外,过去7年我还为许多行业客户提供咨询服务。对于the first client,我在3个月内写了2,000行OCaml,每天20行代码。对于the next client,我们四个人编写了一个编译器,可以在6个月内生成数百万行C / C ++ / Python / Java / OCaml代码以及每个开发人员每天2,000行代码。对于另一个客户,我在6个月内用6kLOC的F#替换了50kLOC的C ++,这是每天-352行代码。对于yet another client,我在F#中重写15kLOC的OCaml,它的大小相同,每天有0行代码。
对于our current client,我将在1年内用约160kLOC的F#代替1,600,000行C ++和Mathematica代码(通过编写定制的编译器),这将是每天-6,000行代码。这将是我迄今为止最成功的项目,每年将为客户节省数百万美元的持续成本。我想每个人都应该每天编写-6,000行代码。
答案 5 :(得分:13)
如果没有真正检查我的“神话人月”(每个读这篇文章的人都应该随手可用),有一章布鲁克斯用线条看待生产力。对他而言,有趣的一点不是每天写入的实际行数,而是在汇编程序和PL / I中看起来大致相同(我认为这是使用的高级语言)。< / p>
布鲁克斯并不打算抛弃任何形式的生产力,但他正在根据真实项目的数据进行工作,而且我记得他们平均每天可能有12行。
他确实指出,生产力可能会有所不同。他说编译器的硬度是应用程序的三倍,操作系统的硬度是编译器的三倍。 (他似乎喜欢使用三乘法来分类。)
我不知道他是否赞赏程序员生产力之间的个体差异(尽管在一个数量级的论证中他确实假设了七个因素的差异),但正如我们所知,卓越的生产力不仅仅是一个问题编写更多代码,但也编写正确的代码来完成工作。
还有环境问题。布鲁克斯推测了一些会让开发人员更快或更慢的原因。像很多人一样,他质疑当前的时尚(使用分时系统进行交互式调试)是否比旧方式更好(仔细预先计划使用整台机器进行两小时的拍摄)。
考虑到这一点,我会忽略他提出的任何无用的实际生产力数字;这本书的持续价值在于人们坚持不学习的原则和更普遍的教训。 (嘿,如果每个人都学过它们,这本书只会有历史意义,就像弗洛伊德所说的那样,就像潜意识一样。)
答案 6 :(得分:11)
每天很容易获得几百行代码。但是,每天尝试获得几百个质量代码,这并不容易。最重要的是通过调试和每天很少或没有新线路的日子,平均值会很快下降。我花了数周时间调试困难问题,答案是1或2行代码。
答案 7 :(得分:10)
更好地认识到,谈论物理代码行是没有意义的。物理代码行(LoC)的数量如此依赖于编码风格,它可以从一个开发人员到另一个开发人员的数量级变化。
在.NET世界中,有一种方便的方法来计算LoC。 序列点。序列点是调试单元,它是在放置断点时以深红色突出显示的代码部分。通过序列点,我们可以讨论逻辑LoC ,并且可以跨各种.NET语言比较此度量。大多数.NET工具都支持逻辑LoC代码度量,包括VisualStudio代码度量,NDepend或NCover。
例如,这是一个8 LoC方法(不考虑开头和结尾括号序列点):
LoC的生产必须长期计算。有些日子你会吐出200多个LoC,有些日子你甚至会花8个小时来修复一个bug甚至没有添加一个LoC。有些日子你会清理死代码并删除LoC,有些日子你会把所有时间花在重构现有代码上,而不是添加任何新的LoC。
就个人而言,我只在以下情况下计算我自己的生产力得分中的单个LoC:
在这种情况下,我在过去5年中为.NET开发人员编写NDepend工具的个人得分是每天 80物理LoC的平均值,而不会牺牲任何代码质量。节奏是持续的,我不认为它会很快减少。总而言之,NDepend是一个C#代码库,目前的权重约为115K物理LoC
对于那些讨厌计算LoC的人(我在这里的评论中看到了很多),我证明一旦经过充分校准,计算LoC是一个很好的估算工具。在编码和测量在我的特定开发环境中实现的许多功能之后,我达到了可以准确估计LoC中任何TODO功能的大小以及将它投入生产所需的时间。
答案 8 :(得分:9)
没有银弹这样的东西。
像这样的单一指标本身就没用了。
例如,我有自己的类库。目前,以下统计数据属实:
总行数: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行代码?
哎呀。
一切都取决于。
你可以让一个顶尖的程序员每天以数千行的顺序生成代码,而一个中等程序员每天生成数百行的代码,质量是一样的。
是的,会有错误。
您想要的总数是余额。代码更改的数量,与发现的错误数量相比,代码的复杂性,以及修复这些错误的困难。
答案 9 :(得分:6)
这意味着: 例如。对于Avionic 250-kLOC项目有40(LOC /月)/ 22(天/月)==&lt; 2LOC /天!
答案 10 :(得分:4)
我认为这来自waterfall development天,项目的实际开发阶段可能只占项目总时间的20-30%。取总代码行除以整个项目时间,你将获得大约10行/天。除以编码周期,你就会更接近人们引用的内容。
答案 11 :(得分:3)
我们的代码库约为2.2MLoC,耗费约150人年。这使得它在整个项目的整个生命周期中每天都有大约 75 的c ++或c#行。
答案 12 :(得分:2)
我认为项目规模和涉及的开发人员数量是这方面的重要因素。在我的职业生涯中,我远远超过了这一点,但我一直独自工作,所以与其他程序员一起工作没有任何损失。
答案 13 :(得分:2)
良好的规划,良好的设计和优秀的程序员。你得到了所有这些,你不会花30分钟写一行。 是的,所有项目都要求你停下来计划,思考,讨论,测试和调试,但是每天两条线路上每个公司都需要一支军队才能让俄罗斯方块工作......
最重要的是,如果你以每小时2行为我工作,你最好给我一些coffes并按摩我的脚,这样你就不会被解雇。
答案 14 :(得分:1)
有人怀疑这个常年经理糖果是因为所有东西都是用C语言编写的系统应用程序而创造出来的,因为如果没有别的东西,幻数会根据应用程序的语言,规模和性质而变化几个数量级。然后你必须打折评论和属性。最终谁关心编写的代码行数?当你达到10K线时,你应该完成吗? 100K?如此武断。
没用。