代码质量[关闭]

问题描述 投票：21回答：19

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

在这样的环境中衡量开发人员绩效的更好方法是什么？

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

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

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

process development-environment
19个回答
23
投票

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

来自Joel的other articles之一：

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

1
投票

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

1
投票

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

您可以花多长时间来修复每个错误，但这很容易发挥 - 添加一个简单的错误，快速修复它，这抵消了修复一个更难修复的诚实到善的错误所花费的时间。

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

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

还有很多其他类似的东西，但是在我的头脑中，这些将对产品的质量产生明显的影响（并且是公正可测量的） - 这是最终目标。

1
投票

即使测试仪在室内或室外，我也不同意“通过Bug计数测量”的概念。

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

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

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

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

1
投票

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

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

1
投票

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

1
投票

我有三件事要说：

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

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

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

1
投票

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

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

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

1
投票

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

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

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

迈克尔

0
投票

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

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

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

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

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

然后引导你的衡量指标来衡量会对系统产生积极影响的某些因素，从而不是测量每个程序员的错误，这只会给管理层带来麻烦，如果事情变坏，试着去测量错误发生的地点和原因，而不是制造错误的人。

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

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

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

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

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

0
投票

这个想法让我想要/ facepalm。

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

我在同一天退出了。

33
投票

alt text

22
投票

11
投票

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

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

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

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

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

5
投票

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

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

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

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

3
投票

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

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

任何可以轻松进行游戏的指标 - 或者让其他人受到测量的激励来进行游戏 - 也是非常糟糕的。

3
投票

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

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

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

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

  • 开发人员是否符合承诺的最后期限？
  • 对客户关注的回应。
  • 任何所需文件的准确性。

可能还有其他人。

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

2
投票

克里斯说得好。

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

2
投票

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

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

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

世界>公司>产品>开发人员

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

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.