代码质量

Question

我为一家软件开发公司工作，我们有大约100人从事产品工作，其中1/3是质量保证。最近管理层希望有一个更好的方法来评估个别程序员的表现，所以建议使用错误报告作为衡量标准。开发者的错误报告越多，他就越糟糕。由于更多的原因，这似乎不明智这是一种测量的主观方式，开发人员针对不同复杂度的不同项目开展工作。另外，如果QA是根据它们生成的错误报告的数量来衡量的，那么会有很多关于错误报告有效性的讨论。

在这种环境下衡量开发人员的表现会更好吗？

一个建议是不使用QA的bug报告作为衡量标准，而是使用外部的bug报告，比如beta测试者，那么当发布这样的公共bug报告时，也要让QA测量它。

编辑：＃1读取你的一些优秀的回答，我在想，用上述的一般问题描述度量之后是它是负面报道的错误 - 它不鼓励生产优质的代码。

编辑：＃2我认为问题在于它是两个世界。一方面有非程序员将程序员视为基本的工作人员，他们希望优先使用度量标准/分钟。然后，我们有程序员，谁想要看自己是艺术家或工匠，“请不要打扰我，我是C - O - D - I - N - 克”:)我不认为测量质量可以通过指标来完成，而不是没有适得其反。相反，一个人对错误，改变意愿，创造力以及高于一切工作质量的反应是重要的，但大多不一定是可衡量的。

Answer 1

试图用错误报告来衡量程序员的表现是一个坏主意。然而，试图通过几乎any other metric来衡量性能。无论你做什么，人们都会弄清楚如何进行游戏并给你所测量的东西，而不会给你真正想要的东西。

从一个乔尔的other articles：

罗伯特·奥斯汀，在他的著作测量和管理组织中的表现，说，有，当你引进新的绩效指标分为两个阶段。起初，你实际上得到了你想要的东西，因为没有人知道如何作弊。在第二阶段，你实际上会遇到更糟糕的情况，因为每个人都会想出最大化你测量的事情的伎俩，即使是以损坏公司为代价。

Answer 2

alt text http://i18.tinypic.com/34461wi.jpg

Answer 3

这是一个可怕的指标，你提到的原因。

此外，“外”错误报告也判断开发商的不公平和不可靠的方式 - 如果有什么一些开发商所使用比别人更多的代码方面的工作？如果我的功能使用了我的80％的用户，而您的使用率为1％，那么您认为哪些人会看到更多的错误报告？

任何可以很容易被玩的指标 - 或者让其他人被测量的奖励来游戏他们 - 也是可怕的。

Answer 4

，以验证质量的唯一途径是审查工作......并衡量什么是审查，返工量。错误是事后方式测量如此---只有一个指标，但在开发过程中的评价也较好。查看一下TopCoder使用的一些指标。

Answer 5

不仅臭虫报告是一个暗示性的措施，但它们并没有真正的可比性。这个bug如何“大”？一个大错误可能比有五个小错误更糟...另一方面它可能不是。所以你需要了解每个bug的具体细节（这将是一场噩梦）。

你可以花多长时间来修复每个bug，但这可以很容易发挥 - 添加一个简单的bug，快速修复，这抵消了修复一个更难的诚实善良bug的时间修理。

您可以使用lint工具和单元测试来提高代码质量而不会受到惩罚。 lint是一个相对简单的过程变化，随着时间的推移你会工作（从现有代码库中的X警告开始，然后奖励那些在一段时间内删除最多警告的人 - 将其转化为积极的而不是负）。

单元测试是另一回事，奖励与最少的错误和大多数测试（如果测试是正确写入那么赔率是最好的测试代码有缺陷最少）的代码。这对开发人员来说也是一个积极的回报和鼓舞人心的事情。测试使代码更好，人们不会受到惩罚。

还有许多其他的像这样的事情，但是从我的头顶这些将有显着的影响（和公正是衡量）对产品的质量 - 这是最终的目标。

Answer 6

最大的问题，我从外地bug报告看到的是，一个程序员可能已经设定100％，他给出的规格，然后在该领域的问题是由于不良或incomplets规格。

让我给你举个例子：你开发和测试在Windows Vista的32位应用程序，然后在要运行64位Windows XP的一个coustomer站点发生故障。是程序员错了吗（特别是如果你从未给他一台运行XP 64位的机器来测试）？

一旦你意识到一个错误可能由于许多原因而出现，其中只有一部分程序员可以控制，你需要非常小心，因为你没有设置一个能够指向指向和设备的环境。团队的所有成员都需要共同努力，使产品更好，而不是花时间试图将错误归咎于别人。

不管你做什么，不要创造一个动力系统中有人被加分证明它是别人的错。错误需要被视为由整个组织所拥有。

Answer 7

我建议你阅读管理实施精益软件开发：从概念到现金，由玛丽·波彭代克和Tom Poppendieck的。他们高度不鼓励根据指标评估开发人员的想法。他们的偏好是奖励团队，而不是个人。

如果这一方法不符合实际情况，我建议你（所以做他们......我想......）同行评审。不要直截了当地说，“你怎么排名你的队友？”，虽然。反而问：当你遇到一个你无法解决的问题时，你会去哪里？谁为项目提供了最佳的创意投入？等等。这些问题的答案可以为谁最大限度地投入团队提供更好的指导。

Answer 8

我不同意“测量错误计数”的概念，即使测试仪在内部或外部。

您可以使用一些关于严重程度的评分机制，而不是直接计算错误数量，即我的意思是衡量程序员的粗心大意。

说一个程序员正在写代码而不处理异常。这个问题比复杂算法中复杂逻辑中的错误要大。因此，对每个错误使用评估机制对于这种情况会更好。在这种情况下，每个错误/错误/错误将得到公平的权重，并且我们可以得到关于使用错误评级总和的性能的总体思想。

另一方面，这种方法也可能造成问题，因为评级也是由人类完成的。但是有一个团队来做这个评级会减少这些问题，并且随着时间的推移，这个机制将会得到更多的可用性，并进行必要的改进和改变。

但它的责任是将错误类别分组并将它们分配给必要的权重..我认为您不能一次执行此操作。这个“定义”也应该随着时间的推移而变得成熟起来。:)

Answer 9

说得好克里斯。

我们在我们的办公室有类似的问题。首席执行官和其他大型假发不知道如何测量开发质量，他们实施了自己的测量。总计一个开发者的bug数量绝对不是衡量标准。我不知道是否有完美的答案，但我希望我的工作能够通过我是否符合我的最后期限和消费者反馈（他们对产品感到满意）来衡量。

Answer 10

这个指标很糟糕，并会鼓励真正的坏习惯和内部斗争，以确定是谁造成了哪个错误。任何度量标准都应该通过测量成功度量来抵消。编写更多代码的人根据定义会有更多错误机会。根据可用的数据，您可能希望将您的评分系统归一化。如果一个开发人员实现了一个没有缺陷的功能，那么我不会以比开发人员更好的方式对他进行评估，这个开发人员实现了243个具有3个缺陷的功能。评级开发人员要求管理层放下数字并观察每个团队成员。积极参与的经理会了解哪些开发人员有缺陷，并会与他们合作以改善他们的表现。这实际上需要管理者的工作来帮助每个人设定目标并达成目标。

Answer 11

Answer 12

开发人员的错误报告是一个可怕的指标。作为质量保证主管，我曾多次争论过这个问题。错误会发生。他们如何处理这些问题更有意义。

更好的指标是开发者的bug重新开放率。换句话说，当质量检查记录了一个错误，然后修正错误，错误是否正确修正，或者错过了一些错误，导致QA重新打开错误？

发生这种情况越频繁，这是开发人员可能没有真正关注该问题的线索。当然，这是假定该错误首先被智能地记录下来，最好是重现步骤，实际结果，预期结果以及原因。屏幕截图也有帮助。

显然，这只是一个要报告的指标。其他可能性有：

• 开发者是否符合承诺的截止日期？
• 对客户问题的反应。
• 准确的任何所需的文件。

和其他可能。

编辑：我已经完成了开发和QA，并且在我的开发过程中很幸运，没有在评论中对我使用错误计数。我当前的公司在我目前的职位上反对它，因为它是IMO不可靠的指标。我们使用重新开放率作为妥协，让高层管理人员（阅读“尖头发型”开发总监）对他们有事要报告感到高兴。我不是经理，实际上也没有自己生成任何报告（如果这是造成一些低估的原因）。

Answer 13

我对这种评分系统的基本问题是，你最终会与你的团队相互竞争，而不是相互合作。如果你知道你可能会支付罚款，那么在代码难度部分工作的动机是什么？只需选择不易出错的更简单的东西。为什么要帮助你的同事改善他们的代码，这样做会使他们受益，并可能会伤害你的评级系统。

我认为使用同伴压力来提高代码质量会更好：没有人想写垃圾，也没有人愿意以废话写作而闻名。真正努力通过TDD驱动缺陷 - 或者至少通过单元测试。转向持续集成并公布谁破坏了构建。在创建任何新的代码之前，让构建者修复它的责任。像这样的事情会提高质量。

一旦所有人都参与了质量目标，对团队而不是个人进行评级。合作共事是一种真正的好处。如果你有懒散的人正在利用这个团队 - 每个人都会知道他们是谁 - 与他们一起改善，如果他们不这样做或者不能，减少你的损失并找到一个更适合团队的人。如果你有合适的人，它可能永远不会达到这一点。如果他们是错误的人，那么你和他们都会更好地了解它，并且继续更好地适应。

如果团队中的某个人真的超越了他们，用一些额外的奖励给他们，但要确保这是一个超越团队其他成员的非凡努力。如果是这样，团队不会介意（太多），因为他们会知道他们的共同报酬很大程度上是由于该人的努力。

显然，以上所有内容都应视为一般规则。虽然他们喜欢称之为管理科学，但它更像是一门艺术。了解你的团队的动态是复杂的业务，但我认为一般规则应该是鼓励和奖励团队合作。

Answer 14

我有三两件事要说一下：

1）谁认为，“较高的错误计数==糟糕的开发者”或“...... ==更好的测试者”可能是一个更大的问题，经理您公司比任何单一的开发人员都难。这个人如何成为关于评估开发者表现的讨论的一部分？如果他们在管理开发人员，他们应该更好地了解。

2）为开发到游戏任何指标相关的bug（错误计数，重新打开率，正火或不按功能/ LOC /不管）就是让自己的执行情况很难测试，因为他们可以最简单的方法。不可能测试意味着QA发现零错误。也可能无法使用，这意味着来自该领域的零错误报告（嗯，也许是一个）。任何错误计数指标都是与可测性的激励。询问管理层是否真的是他们想要的。3）如果他们真的实施了这个政策，就像地狱一样运行。

Answer 15

在实施任何类型的指标之前，先问问自己......最终......您要衡量的是什么？

- 程序员的生产力是你没有听？嗯

- 是啊当然..但为什么这很重要？

让人参与指标将不可避免地尝试为了他们自己的目标对其进行优化，因此，知道这一点后，您应该能够利用这种优化来获得优势。

• 问问自己，然后问问自己，如果有人优化指标，他们将集中在什么？

然后直接测量成才，将积极地影响系统的指标，因此，不是测量每程序员只给弹药管理火，如果事情变坏，试图测量位置和原因的错误发生的错误，不是谁制造的。

因此，每个模块的错误，每个版本的错误，每次代码修复的错误，每个功能的错误将是更高效的指标，并且有助于识别热点。当然，你总是可以把它与某人联系起来，因为总是与程序员有间接的联系，但是在你把程序员放在责备战争的最前沿之前，你最好确保HE-SHE是原因。

• 问问自己想要创建什么样的环境？团队，经理，董事面对指标出版时会有什么反应？

如果你测量的人，并使他们看起来不好，那么你是在要求麻烦。如果你对产品进行评估，那么重点不会放在让自己看起来不错但让产品看起来很好。这反过来将是一个更好的激励者，并将培养积极的团队精神。

• 公开你的度量标准，任何形式的信息隐藏都会导致不良反应和不公正。因此，如果您公布您的指标，请仔细阅读他们的评论。

最后，如果你真的在测量人，然后衡量他们所有人，程序员，建筑师，经理，销售人员，董事都应该有相同的审查。然后隐藏刀子并将金属探测器放置在门上。通常原因在于，公司内部人员的透明度只能以一种方式进行，从顶部向下看。

Answer 16

我们是专业人士，就像很多人一样。我们也相信我们是艺术家，在我看来我们是。不幸的是（大多数）程序员是拥有赞助人的艺术家。

通过说没有可行的度量衡量我们是说“只留下我们，我们会做我们的工作”。那可能适用于你，但你有多少同事，你只是希望你有一个数字来表明他们是多么糟糕？主观性很好，让我们都感觉更好，并为经理创造了不错的薪水，但我们做需要一些程序员熟练程度。

如果我们自己没有拿出让管理层感到满意的东西，那么他们会做与艺术赞助人一样的事情。 “我不喜欢它，你被解雇了。”

世界>公司>产品>开发

对于特定指标，我像失去了其他人一样。我看到的最好的是重新开放的错误指标。

Answer 17

阅读一些你出色 答复后，我在想，上述 的 一般问题描述指标是，它是 负面报道的错误 - 它不 鼓励生产优质的代码。

的确如此。而且你会遇到同样的麻烦，你应用的任何其他指标。关键问题是质量不是我们知道如何进行数字测量的。此外，主要是如果您正确地完成工作，您不应该关心代码质量问题。你真正的问题应该是，“这个人怎么帮我们赚钱？”

评估不是你可以用数字做的事情，但它是你必须要做的事情。我可以给你的最好的建议是，你的经理只需要和程序员一起工作，了解程序员在做什么。另一个重要的信息来源来自程序员的同行，他们每天都与他们一起工作。由于我们没有一种数值方法来衡量质量，所以您在某种程度上必须依靠较软的科学来深入了解您的程序员的表现如何。

Answer 18

QA发现的错误=好。 客户发现的错误=错误。

如果您需要测量开发人员，请使用在测试后发现的#bugs，即在光盘上的生产/发布/版本中。

质量保证同样的指标......“一个团队一个梦想”。

迈克尔

Answer 19

这个想法只是让我想/ facepalm。

嗯，10年前我有一个老板，他建议我为SLOC付钱。

我在同一天离开。