因此,人们普遍认为顶级程序员可以产生一个数量级的更好的代码,而不是普通的同龄人。
对于程序员来说,代码中的错误率为相对常数也是被普遍接受的。
相反,它往往会受到在编写代码和编写代码之后使用的进程。的影响。(据我所知)人类往往以相当恒定的速度犯错误--更好的程序员只是注意到它们中的更多,并且更快地修复它们。
所以我最近开始在我的代码中看到这个。我可以用更高的质量(基于性能指标和签入后所做的更改),计算出大约4-5倍的代码量(由团队估计的故事点来衡量)。但我还是会犯错。在更好的单元测试、更好地理解代码正在做什么以及在进行代码评审时对问题有更好的洞察力之间,我不会产生4-5倍的bug。
但是,我仍然产生了大约两倍于我的团队中的其他开发人员发现的But。正如您可能想象的那样,这会导致非技术人员进行度量测量时出现一些问题(请阅读:我的老板)。
我曾试图指出,我的错误生成率是同龄人的一半(并且修复了两倍的错误),但是当有图表显示我产生了两倍的but时,这是很难接受的。
那么,如何处理这样一个事实,即生产力的提高会导致更多的bug?
发布于 2014-05-15 17:41:30
花一些额外的时间清理,抛光和测试你的代码。仍然会有错误,但会少一些。这需要时间。您的代码输出率将下降,但您的无bug代码输出将增加,这将导致更高的生产力。因为虫子很贵。
您能否将代码保存在分支或测试环境中,直到您踢开它并捕获更多的bug?分支中的bug通常比生产代码中的bug引起的波动小。
但我不完全是在挖掘你的断言导致你的问题。也许你的老板也不是。
我不认为每一个编码器产生相同的错误率。您的第二个链接实际上是完全脱离主题,因为它是比较不同的语言,而不是不同的编码器技能水平。complete提到了一些大样本的度量,它们是在观察过程,而不是编码者的技能。当他们说顶级编码程序产生更多/更好的代码时,这部分意味着它有更少的bug。取决于应用程序。所以,是的,我认为这是一个不同的观点的问题。
最后,如果老板想要更干净的代码,就给他更干净的代码。
发布于 2014-05-15 21:00:29
假设您会在20%的时间内生成与您的同事相同的“数量”代码,那么您可以花费4倍的时间来调试代码并使其变得完美,这将进一步降低您的错误率。然后你就可以称自己是一个优秀的程序员。
最大的问题是,为什么你编码的5倍,而不是以质量为目标。这是你的自我要求你还是你的老板强迫你?
此外,您还需要考虑修复bug的成本。当您尽早找到它时,您可能仍然“在”代码中,足以快速修复它。如果它只出现在另一个月的开发,它可能很难找到,甚至强迫你改变大部分已经编程的代码。
你似乎拥有生成代码的技能,如果你把注意力放在质量上而不是速度上,你可能会变得很棒。试一下,我猜你会喜欢的。
接下来的问题是,为了你更好的表现,如何得到认可(说话)。跟你的老板谈谈,问他该怎么做,毕竟这是他的公司和钱,如果他想让你少出一点问题,他也应该决定以哪种方式发生。
发布于 2014-05-17 21:07:28
试图启发管理是不可能的。有句老话,“你是要相信我,还是相信你说谎的眼睛?”你的老板关心的是窃听器的数量。再多的合理化也不能告诉他们这是可以接受的。风险是现在的两倍多。此外,您并不是唯一受bug计数影响的人。QA有两倍的工作试图识别您的错误,所以管理层希望您减少它们。
最好的解决方案是减少您所产生的bug的数量。管理人员不仅会更快乐,你也会更快乐。你不会吧?因为我敢肯定,尽管你喜欢夸耀你的表现比你的同事高出四倍,但你还是愿意说你这样做的次数和他们一样多,甚至更少。
正如您所说的,"…代码…中的错误率往往会受到编写代码时和编写代码之后所使用的进程的影响。“如果您想要更改生成bug的速度,则必须更改用于编写代码的进程。
程序员使用生产方法来生成代码,就像装配线使用方法来产生大量生产的对象一样。好吧,软件业的做法更像是从树林里找到的树枝上削小技巧。但既然我们生产的机器,我们应该采用同样的严谨和纪律,用于高速机器的大规模生产。
这包括在批量生产中使用的降低缺陷率的相同技术:根本原因分析,以确定错误产生的原因,并更改过程,使其不产生错误,或者至少在QA之前就发现了错误。
你所发现的可能会使你走得更慢。另一方面,它可以帮助您更快地生产,因为您将有较少的需要返工的东西,你已经放在你的身后。实际上,四倍的代码并不比你的同事好四倍,所以改变你的流程绝对是可行的。
https://softwareengineering.stackexchange.com/questions/239158
复制相似问题