blocks|key|2560770|text|您还可以考虑映射缺陷发现率和缺陷解决率...查找bug需要多长时间，一旦发现它们，修复它们需要多长时间？据我所知，TDD应该在修复时间上有所改进，因为它可以更早地发现缺陷……对吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2560771|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You may also consider mapping defect discovery rate and defect resolution rates... how long does it take to find bugs, and once they're found, how long do they take to fix? To my knowledge, TDD is supposed to improve on fix times because it makes defects known earlier... right?

blocks|key|2553610|text|任何度量都是对缺陷和代码大小的任意比较；只要比较是相似的，它就应该起作用。例如，C中的缺陷/kloc到C中的缺陷/kloc。如果你改变了语言，它在任何情况下都会影响度量标准，因为用另一种语言编写的同一个程序可能不太容易出现缺陷。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2553611|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Any measure is an arbitrary comparison of defects to code size; so long as the comparison is similar, it should work. E.g., defects/kloc in C to defects/kloc in C. If you changed languages, it would affect the metric in any case, since the same program in another language might be less defect-prone.

blocks|key|96921|text|我建议使用时间之间的比率：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|96922|修复bugs|96923|the花费的时间|unordered-list-item|96924|花费的时间编写其他代码的时间|ordered-list-item|96925|96926|96927|这似乎在所有语言中都有效...|96928|96929|如果你只对一些大的代码库有一个粗略的估计，它也是有效的。您仍然可以将其与您正在编写的新代码进行比较，以给您的管理层留下深刻印象;-)|96930|entityMap^0|A|3|0|0|6|0|0|0|E|0|0|0|0|F|0|0|0|1U|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|13|8|@$9|14|A|15|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|17|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|18|8|@$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|R|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]|$1|S|3|T|5|6|7|1C|8|@$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1F|8|@]|D|@]|E|$]]]|V|$]]

I suggest to use the ratio between the times :

<ol>
<li>the time spend fixing bugs</li>
<li>the time spend writing other codes</li>
</ol>

This seem valid across languages...

<hr>

It also works if you only have a rough estimation of some big code base. You can still compare it to the new code you are writing, to impress you management ;-)

blocks|key|2553628|text|测量缺陷并不是一件容易的事情。有人想要解释代码的复杂性，但这是令人难以置信的混乱和令人不快。在衡量代码质量时，我建议：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2553629|2553630|测量当前状态(您现在的缺陷率是多少)|ordered-list-item|2553631|进行更改(同行评审、培训、代码指南等)|2553632|测量新的缺陷率(Have+things+improved?)|2553633|Goto+2|2553634|2553635|如果您要比较程序员，请确保您比较的是使用相同语言执行类似工作的程序员。不要将在最复杂的计算引擎内部工作的程序员与编写在数据库中存储内容的代码的程序员进行比较。|2553636|我试图确保程序员知道这个过程是被测量的，而不是编码者。这有助于提高指标的质量。|2553637|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|X|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Measuring defects isn't an easy thing. One would like to account for the complexity of the code, but that is incredibly messy and unpleasant. When measuring code quality I recommend:

<ol>
<li>Measure the current state (what is your defect rate now) </li>
<li>Make a change (peer reviews, training, code guidelines, etc) </li>
<li>Measure the new defect rate (Have things improved?)</li>
<li>Goto 2</li>
</ol>

If you are going to compare coders make sure you compare coders doing similar work in the same language. Don't compare the coder who works in the deep internals of your most complex calculation engine to the coder who writes the code that stores stuff in the database. 

I try to make sure that coders know that the process is being measured not the coders. This helps to improve the quality of the metrics.

blocks|key|2553650|text|我对所有与LOC相关的度量都持怀疑态度，这不仅仅是因为语言的相对表达能力不同，还因为各个程序员在代码的表达能力上会有很大的差异，以至于这个度量充其量是“模糊的”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2553651|从项目管理的利益出发，我要衡量的事情是：|2553652|项目中公开缺陷的|2553653|Number。没有单一的标量可以告诉你项目在哪里，以及它离可发布状态有多近，但这仍然是一个手头上的方便的数字，可以监视time.|unordered-list-item|offset|length|style|BOLD|2553654|Defect检测率。这不是系统中引入新缺陷的速率，但它可能是你最接近的代理解决方案。如果这个低于检测率，你就落后了-如果它更高，你快成功了。|2553655|2553656|如果您将这些数字与严重性信息结合起来，则所有这些数字都会更有用。一个有20个小bug的产品可能比一个有2个崩溃bug的产品更接近发布。如果您清除的是轻微的错误，而不是严重的错误，则必须让开发人员重新关注他们的注意力。|2553657|我会跟踪每个项目和每个开发人员的这些数字。每个项目这样做的原因应该是明确的。每个开发人员的数字当然不是单个贡献者的技能或生产力的全部情况，但可以为您指出可能需要培训或补救的人。|2553658|您可能还希望通过项目模块来标记缺陷跟踪系统中的所有票证(特别是对于较大的项目)，这样您就可以知道何时关键模块处于脆弱状态。|2553659|entityMap^0|0|0|0|0|1S|0|0|16|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Z|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|10|8|@$I|11|J|12|K|L]]|9|@]|A|$]]|$1|M|3|N|5|H|7|13|8|@$I|14|J|15|K|L]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|16|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|17|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|18|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|W|$]]

I'm skeptical of all LOC-related measurements, not just because of different relative expressiveness of languages, but because individual programmers will vary enough in the expressiveness of their code as to make this metric "fuzzy" at best.

The things I would measure in the interests of project management are:

<ul>
<li>Number of open defects on the project. There's no single scalar that can tell you where the project is and how close it is to a releasable state, but this is still a handy number to have on hand and watch over time.</li>
<li>Defect detection rate. This is not the rate of introduction of new defects into the system, but it's probably the closest proxy you'll find.</li>
<li>Defect resolution rate. If this is less than the detection rate, you're falling behind - if it's greater, you're getting ahead.</li>
</ul>

All of these numbers are more useful if you combine them with severity information. A product with 20 minor bugs may well closer to release than one with 2 crashing bugs. If you're clearing the minor bugs but not the severe ones, you have to get the developers to refocus their attention.

I would track these numbers per project and per developer. The reason for doing them per project should be clear. The per-developer numbers are certainly not the whole picture of an individual contributor's skill or productivity, but can point you to people who might need training or remediation.

You may also wish to tag all the tickets in your defect tracking system by project module as well (especially for larger projects), so that you can tell when critical modules are in a fragile state.

blocks|key|97012|text|为什么你不考虑每个用例的缺陷？或每个需求的缺陷。我们在到达KLOC的过程中遇到了一些实际问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|97013|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Why dont you consider defects per use case ? or defects per requirement. We have faced practical issues in arriving at the KLOC.

I'm trying to create some internal metrics to demonstrate (determine?) how well TDD improves defect rates in code.

Is there a better way than defects/KLOC? What about a language's 'functional density'?

Any comments or suggestions would be helpful.

Thanks - Jonathan

What is Best for Defect Rate Tracking? Defects per KLOC?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我正在尝试创建一些内部指标来演示(确定？)TDD如何提高代码中的缺陷率。还有比缺陷/KLOC更好的方法吗？那么语言的“函数密度”呢？任何评论或建议都会很有帮助。谢谢-乔纳森

问什么是最好的缺陷率跟踪？每个KLOC的缺陷？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是最好的缺陷率跟踪？每个KLOC的缺陷？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是最好的缺陷率跟踪？每个KLOC的缺陷？
EN