代码质量

Question

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

在这种情况下衡量开发人员业绩的更好方法是什么？

一个建议是不使用来自QA的错误报告作为衡量标准，而是使用来自外部的错误报告，例如beta测试人员，然后发布此类公开错误报告时，也要让QA通过它来衡量。

编辑：＃1在阅读了一些优秀的回复之后，我认为上述指标的一般问题是它是负面的报告错误 - 它不鼓励产生高质量的代码。

编辑：＃2我认为问题在于它是两个世界。一方面有非程序员基本上将程序员视为工人，他们最好需要度量单位/分钟。然后，我们让那些希望将自己视为艺术家或工匠的程序员，“请不要打扰我，我是c-o-d-i-n-g”:)我不认为测量质量可以通过指标来完成，而不是适得其反。相反，一个人如何对错误作出反应，改变意愿，创造力以及最重要的工作质量是重要的，但大多不一定是可衡量的。

Answer 1

Answer 2

尝试使用错误报告来衡量程序员的表现是一个坏主意。但是，尝试使用虚拟any other metric来衡量效果也是如此。无论你做什么，人们都会想出如何游戏并给你你正在测量的东西而不给你你真正想要的东西。

来自乔尔的一个other articles：

  罗伯特·奥斯汀（Robert Austin）在他的“衡量和管理组织绩效”一书中说，当您引入新的绩效指标时，有两个阶段。起初，你实际上得到了你想要的东西，因为没有人知道如何作弊。在第二阶段，你实际上会变得更糟，因为每个人都会想出最大化你所测量的东西的技巧，即使以毁掉公司为代价。

Answer 3

Answer 4

我对此类评级系统的基本问题是，您最终会与您的团队相互竞争，而不是彼此合作。如果您知道可能会支付罚款，那么在代码的难点部分工作的动机是什么？只需挑选容易出错的简单事物。为什么帮助您的同事改进他们的代码，这样做有利于他们，并可能对评级系统造成伤害。

我认为你最好利用同伴压力来提高代码质量：没有人想写垃圾，也没有人想以编写垃圾而闻名。用TDD做出真正的努力来减少缺陷 - 或者至少用单元测试。转向持续集成并宣传谁破坏了构建。在创建任何新代码之前，让破坏构建的人负责修复它。这样的事情会提高质量。

一旦每个人都参与质量目标，就要对团队进行评分，而不是对个人进行评分。使合作工作真正受益。如果你有利用团队的懒鬼 - 每个人都会知道他们是谁 - 与他们一起改善，如果他们不能或不能，减少你的损失并找到一个更适合团队的人。如果你有合适的人选，它可能永远不会达到这一点。如果他们是错误的人，那么你和他们都会更好地了解它并继续更好地适应。

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

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

Answer 5

我看到来自现场的错误报告的一个大问题是，程序员可能已经按照他给出的规格进行了100％的编程，然后该领域的问题是由于规格不足或不完整。

让我举个例子：您在Windows Vista 32位上开发和测试应用程序，然后在运行64位WIndows XP的coustomer网站上失败。这是程序员的错吗（特别是如果你从来没有给他一台机器运行XP 64位进行测试）？

一旦你意识到错误可能由于很多原因而出现，只有程序员可以控制的一些，你需要非常小心，不要设置一个导致指责和指责的环境。团队的所有成员需要共同努力才能使产品更好，而不是花费一天时间将错误归咎于其他人。

无论你做什么，都不要创建一个奖励系统，在这个系统中，有人获得奖励积分，证明这是别人的错误。需要将错误视为整个组织所拥有的错误。

Answer 6

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

此外，“外部”错误报告对于判断开发人员也是一种不公平且不可靠的方式 - 如果某些开发人员处理的代码区域比其他开发人员使用得多，该怎么办？如果使用我的功能，我的80％用户和1％的用户使用，您认为谁会看到更多错误报告？

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

Answer 7

开发人员的错误报告是一个可怕的指标。作为QA领导，我一次又一次地反对。错误将发生。如何处理它们更有意义。

更好的指标是开发人员的错误重启率。换句话说，当QA记录一个错误（然后修复）时，错误是否正确修复，或者是否有错过的错误导致QA重新打开错误？

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

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

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

可能还有其他人。

编辑：我已经完成了开发和质量保证，并且在开发期间很幸运，没有在评论中使用错误计数。我现在担任现任公司的反对意见，因为这是一个不可靠的指标IMO。我们使用重新开放率作为折衷方案，使高层管理人员（阅读“尖头发”开发导演）对他们有什么需要报告感到高兴。我不是经理，实际上我自己也没有生成任何报告（如果是造成一些贬值的原因）。

Answer 8

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

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

如果我们自己没有想出让管理层满意的事情，那么他们就会像艺术顾客那样做。 “我不喜欢它，你被解雇了。”

世界＆gt;公司＆gt;产品＆gt;显影剂

至于一个特定的指标，我和其他人一样迷失方向。我看到的最好的是重新打开的错误指标。

Answer 9

克里斯说得好。

我们办公室遇到了类似的问题。首席执行官和其他大型假发不知道如何测量开发质量，他们实施了自己的简洁测量。总计开发人员错误数量绝对不是衡量标准。我不知道是否有一个完美的答案，但我希望我的工作取决于我是否符合我的截止日期和消费者反馈（他们是否对产品感到满意）。

Answer 10

这个指标很糟糕，并且会鼓励真正糟糕的做法和内心，因为谁造成了哪个错误。任何度量标准都应该通过衡量成功的度量来抵消。根据定义，编写更多代码的人会有更多的错误机会。根据可用数据，您可能希望规范您的评级系统。如果一个开发人员实现了一个没有缺陷的功能，那么我不会以比用3个缺陷实现243个功能的开发人员更好的方式评价他。评级开发人员要求管理层将数字放在一边并观察每个团队成员。积极参与的经理将了解哪些开发人员有缺陷，并将与他们合作以改善他们的表现。这实际上需要管理者的工作来帮助每个人设定和实现目标。

Answer 11

QA发现的漏洞=好。 客户发现的错误=糟糕。

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

QA的相同指标......“一个团队一个梦想”。

迈克尔

Answer 12

  

看完你的一些优秀   回答我当时在想   与上述一般问题   所描述的指标就是它   否定报告错误 - 它没有   鼓励制作高质量的代码。

这是事实。您应用的任何其他指标都会遇到同样的问题。关键问题是质量不是我们知道如何以数字方式衡量的。另外，如果你正确地完成工作，你不应该真正关心代码质量的问题。你真正的问题应该是，“这个人如何帮助我们赚钱？”

评估不是你可以用数字做的事情，但它是你必须要做的事情。我能给你的最好建议是你的经理只需要与程序员合作，并了解程序员在做什么。另一个重要的信息来源是程序员的同事，他们日复一日地与他们合作。由于我们没有数字方法来衡量质量，因此您将在某种程度上依靠较软的科学来深入了解您的程序员的表现。

Answer 13

我有三件事要说：

1）经理人建议“更高的错误数= =更差的开发人员”或“...... =更好的测试人员”对您的公司来说可能比任何一个开发人员都要大。这个人是如何成为评估开发人员绩效的讨论的一部分？如果他们管理开发人员，他们应该更清楚。

2）开发人员游戏任何指标与错误相关的最简单方法（错误计数，重新开放率，规范化或不符合功能/ LOC /无论如何）都是为了让他们的实施难以实现尽可能地测试。无法测试意味着QA发现零漏洞。也可能无法使用，这意味着来自现场的零错误报告（好吧，也许一个）。任何错误计数指标都是针对可测试性的激励。询问管理层是否真的是他们想要的。

3）如果他们真的实施了这个政策，就像地狱一样运行。

Answer 14

即使测试人员在室内或室外，我也不同意“按计数测量”的概念。

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

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

另一方面，这种方法也会产生问题，因为评级也是由人类完成的。但是，拥有一个团队来进行此评级将减少此类问题，并且该机制将随着时间的推移而变得更加可用，并进行必要的改进和更改。

但是你有责任对错误类别进行分组，并为它们分配必要的权重。我认为你不能立刻做到这一点。随着时间的推移，这个“定义”也应该随着修正而成熟..：）

Answer 15

我建议您的管理层阅读Mary Poppendieck和Tom Poppendieck的实施精益软件开发：从概念到现金。他们强烈反对基于指标评估开发人员的想法。他们倾向于奖励团队，而不是个人。

如果这种方法不实用，我建议（他们也是......我认为......）同行评审。不要用“你怎么对你的队友进行排名？”这样的直言不讳地说它。请问：当你遇到无法解决的问题时，你会去谁？谁为项目提供了最好的创意投入？这些问题的答案可以为谁最大限度地融入团队提供更好的指导。

Answer 16

不仅bug报告是一种暗示性措施，而且它们不具有可比性。这个bug有多“大”？一个大错误可能比有5个小错误更糟糕......另一方面它可能不是。因此，您需要了解每个错误的细节（这将是一场噩梦）。

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

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

单元测试是另一回事，用最少的错误和大多数测试来奖励代码（如果测试是正确编写的，则可能性最好的代码将具有最少的错误）。对于开发人员来说，这是一个积极的回报和令人鼓舞的事情测试使代码更好，人们不会受到惩罚。

还有很多其他类似的事情，但是我不知道这些产品的质量会产生明显的影响（并且是公正的可测量的） - 这是最终目标。

Answer 17

验证质量的唯一真正方法是审核工作......并衡量审核内容和返工量。在事实之后，错误测量这个 - 并且只有一个指标，但在开发过程中的评论更好。查看TopCoder使用的一些指标。

Answer 18

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

- 程序员的生产力你不听吗？咄

- 是的，但是为什么这很重要？

将人类纳入指标将不可避免地尝试根据自己的目标对其进行优化，因此，了解这一点，您应该能够利用此优化。

• 问问自己，是否有人优化了指标，他们会集中注意力？

然后指导您衡量一些会对系统产生积极影响的指标，从而不是测量每个程序员的错误，只会让管理人员发现错误，如果事情变坏，请尝试测量错误发生的位置和原因，而不是制造者它们。

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

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

如果你测量人，让他们看起来很糟糕，那么你就是在寻找麻烦。如果您购买产品，那么重点不在于让自己看起来不错，而是让产品看起来更好。这反过来将是一个更好的激励因素，并将培养积极的团队精神。

• 公开您的指标，任何形式的信息隐藏都会导致不良反应和不公正。因此，如果您宣传您的指标，请注意他们所说的内容。

最后，如果你真的想要衡量人，那么衡量一切，程序员，建筑师，经理，推销员，董事都应该受到同样的审查。然后隐藏刀具并在门上放置金属探测器。通常情况下，公司内部人员的透明度只能单向运作，从顶部向下看。

Answer 19

这个想法让我想要/ facepalm。

好吧，我自己有一个老板，10年前谁建议付我SLOC。

我在同一天退出。