每个开发者日神话人月10行 - 大型项目有多近？
每个人总是说他们可以从"神话人月"中击败"每个开发者每天10行",并且开始一个项目,我通常可以在一天内获得几百行.
但在我以前的雇主中,所有开发人员都非常敏锐,但这是一个大型项目,超过一百万行代码,具有非常繁重的认证要求,并与其他数百万行项目连接.在某些时候,作为一种好奇心的练习,我在我的小组中的运输产品中绘制了代码行(不包括我们开发的工具),当然,逐步地,每个开发人员每天增加大约12行净添加.不计算更改,测试代码或开发人员每天都没有处理实际项目代码的事实.
其他人怎么样？你面临什么样的要求(我想象它是一个因素)？
CB *_*ley 108
在我目前的一个项目中,在某些模块中,我很自豪地为代码库贡献了负数.确定哪些代码区域变得不必要的复杂性,并且可以通过更清晰,更清晰的设计进行简化,这是一项非常有用的技能.
当然,一些问题本质上是复杂的并且需要复杂的解决方案,但是在大多数大型项目中,需求定义不明确或需求变化较大的区域往往会出现过于复杂的解决方案,每行的问题数量更多.
鉴于要解决的问题,我更喜欢减少行数的解决方案.当然,在小项目开始的时候,我每天可以生成十多行代码,但我不会想到我编写的代码量,只考虑它的功能以及执行的程度.我当然不会打算每天打十行或者认为这是一个成就.
- +1为贡献负线.我曾经做过一个小项目,在这里我将线数从15K减少到5K,同时增加了新功能(并且大大减少了错误数量并提高了速度). (49认同)
Lir*_*evi 46
我认为添加的行数很大程度上取决于项目的状态,添加到新项目的速度将远高于启动项目的速率.
两者之间的工作是不同的 - 在一个大型项目中,您通常会花费大部分时间来计算部件之间的关系,而只需要少量实际更改/添加.而在一个新项目中 - 你主要是写...直到它足够大并且速率降低.
Otá*_*cio 30
您应该停止使用此指标,这在大多数情况下毫无意义.内聚,耦合和复杂性是比代码行更重要的指标.
- 我没有将它用作生产力指标.这是我自己好奇的私人运动. (25认同)
- 很公平.即便如此,如果没有更准确地定义什么是一行代码就很难回答. (3认同)
Jon*_*rop 28
其他人怎么样？
我是唯一的专职开发公司和已经写50万线的OCaml和F#代码在过去的7年,这相当于约200每天的代码行.但是,绝大多数代码都是由数百个单独项目组成的教程示例,每个项目都有几百行.此外,OCaml和F#之间存在很多重复.我们没有维护任何大于50kLOC的内部代码库.
除了开发和维护我们自己的软件外,过去7年我还为许多行业客户提供咨询服务.对于第一个客户,我在3个月内写了2,000行OCaml,每天20行代码.对于下一个客户端,我们四个人编写了一个编译器,可以在6个月内生成数百万行C/C++/Python/Java/OCaml代码以及每个开发人员每天2,000行代码.对于另一个客户,我在6个月内用6kLOC的F#替换了50kLOC的C++,这是每天-352行代码.对于另一个客户端,我在F#中重写15kLOC的OCaml,其大小相同,每天0行代码.
对于我们当前的客户,我将在1年内用约160kLOC的F#替换1,600,000行C++和Mathematica代码(通过编写定制的编译器),每天将有-6,000行代码.这将是我迄今为止最成功的项目,每年将为客户节省数百万美元的持续成本.我想每个人都应该致力于每天编写-6,000行代码.
- @ mm24"你能澄清为什么重写F#中的代码会为你的客户省钱".首先,他们真的被Wolfram Research搞砸了,他们向他们收取100万英镑的咨询合同,以解决他们故意在Mathematica升级中引入的问题,例如改变\ [LongDash]的语义.其次,他们整合了两个代码库(Mathematica和C++),这两个代码库目前同时保存在一个F#代码库中,不仅减少了重复工作量,还减少了测试中发现的产品更新和修复的许多交互. (7认同)
- @ mm24第三,自动化.他们手工做很多事情,既有预先存在的自动化.NET工具,也有.NET可以轻松构建这样的工具.任务包括使用定时器测量代码以测量性能(使用分析器),手动编写序列化器(使用库),手动复制键值名称(使用反射)以及对业务提交的实时系统的关键更新由人员执行IT手工编写(编写工具,以便业务可以直接进行更改). (7认同)
- @ mm24第四,大规模的性能提升.F#比Mathematica快几个数量级,并且它们在F#中的概念验证代码比它们的生产C++代码快5倍.这意味着测试在几秒而不是几小时内执行,此时测试成为开发不可或缺的一部分,从而显着提高了生产力. (7认同)
- @ mm24第五,增强能力.他们希望消除死代码并测量他们测试的代码覆盖率,但他们无法使用他们所使用的工具来做到这一点.迁移到.NET使这个(以及更多!)变得容易. (7认同)
Dav*_*ley 13
如果没有真正检查我的"神话人月"的副本(每个读这篇文章的人都应该随手可得),有一章布鲁克斯用线条看待生产力.对他来说,有趣的一点不是每天写的实际行数,而是汇编程序和PL/I中的大致相同的事实(我认为这是使用的高级语言).
布鲁克斯不打算抛出某种任意生产力的数字,但他正在根据实际项目的数据进行工作,而且我记得他们平均每天可能有12行.
他确实指出,生产力可能会有所不同.他说编译器的硬度是应用程序的三倍,操作系统的硬度是编译器的三倍.(他似乎喜欢使用三个乘数来分类.)
我不知道他是否赞赏程序员生产力之间的个体差异(尽管在一个数量级的论证中他确实假设了七个因素的差异),但正如我们所知,卓越的生产力不仅仅是写更多的问题代码,但也写出正确的代码来完成这项工作.
还有环境问题.布鲁克斯推测了一些会让开发人员更快或更慢的原因.像很多人一样,他质疑当前的时尚(使用分时系统的交互式调试)是否比旧的方式更好(使用整个机器仔细预先计划两小时).
鉴于此,我会忽略他提出的任何无用的实际生产力数字; 这本书的持续价值在于人们坚持不学习的原则和更普遍的教训.(嘿,如果每个人都学过它们,这本书只会有历史意义,就像弗洛伊德所说的那样,就像潜意识一样.)
- 关于不同程序员生产力的思考 - 根据我的经验,一个平庸的程序员将花费x倍的时间来解决给定的问题,但不幸的是,在编写代码时会编写x倍的代码.因此,通过简单的"每日代码行",平庸的程序员同样富有成效. (3认同)
Jef*_*nes 11
每天很容易获得几百行代码.但是,每天尝试获得几百个质量代码,这并不容易.最重要的是通过调试和每天很少或没有新线路的日子,平均值会很快下降.我花了数周时间调试困难问题,答案是1或2行代码.
- 呸! 你的语法有bug ... (14认同)
- @DanielMoura哦,我不同意这个......"你好世界"程序可能不是很有用,但是你可以非常自信地说它没有任何错误:) (3认同)
Pat*_*eam 10
能够更好地认识到,谈论物理代码行是毫无意义的.物理代码行(LoC)的数量如此依赖于编码风格,它可以从一个开发者到另一个开发者变化一个数量级.
在.NET世界中,有一种方便的方法来计算LoC.序列点.序列点是调试单元,它是在放置断点时以深红色突出显示的代码部分.通过序列点,我们可以讨论逻辑LoC,并且可以跨各种.NET语言比较该度量.大多数.NET工具都支持逻辑LoC代码度量,包括VisualStudio代码度量,NDepend或NCover.
例如,这是一个8 LoC方法(开始和结束括号序列点不考虑):
LoC的生产必须长期计算.有些日子你会吐出200多个LoC,有些日子你甚至会花8个小时来修复一个bug甚至没有添加一个LoC.有些日子你会清理死代码并删除LoC,有些日子你会花费所有时间来重构现有代码而不是添加任何新的LoC.
就个人而言,我只在以下情况下用自己的生产力得分计算单个LoC:
- 它由单元测试覆盖
- 它与某种代码合同相关联(如果可能的话,并非所有的LoC当然都可以通过合同来检查).
在这种情况下,我在过去5年中为.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-02-13,大约2600天,平均每天48行代码.
所有这些代码都很好？哎呀 但每天最多12行代码？
哎呀
一切都取决于.
你可以让一流的程序员每天按照数千行的顺序生成代码,而一个中型程序员每天生成几百行的代码,质量也是一样的.
是的,会有错误.
你想要的总和就是余额.代码更改的数量,与发现的错误数量相比,代码的复杂性,以及修复这些错误的困难.
- 也许每天10行规则不适用于较小的东西,比如你写的类库(我自己假设).Brooks的大部分数据都来自大型项目(IBM的OS360),这个项目的规模与您的类库完全不同.我的猜测是,布鲁克斯的观察结果(经常)对需要很多人和重要的人际交流网络的大型项目有效,但对小型项目无效. (5认同)
Steve McConnell在他的"软件估算"一书中给出了一个有趣的统计数据(p62表5.2)他区分项目类型(Avionic,Business,Telco等)和项目规模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 /天!