我的故事点数比平均水平高4-5倍，但错误产生率却是平均水平的一半。图说它的错误多出2倍，如何处理？

因此，通常公认的是，顶级程序员可以比普通程序员产生更多/更好的代码。

人们也普遍认为，对于程序员而言，代码中的错误率相对恒定。

相反，它倾向于受到编写代码时和编写代码后使用的过程的影响。（据我了解）人类倾向于以相当恒定的速度犯错误-更好的程序员只会注意到更多的错误，并且会更快地解决它们。

• 请注意，以上两个断言都来自史蒂夫·麦康奈尔（Steve McConnell）的Code Complete，因此这不是不同观点的问题。

因此，我最近开始在代码中看到这一点。我可以像其他同等人（以团队估计的故事点来衡量）的代码量提高大约4-5倍，并且质量更高（基于性能指标和签入后所做的更改数量）。但是我仍然会犯错误。在进行更好的单元测试，更好地理解代码的功能以及更好地了解代码审查时的问题之间，我没有产生4-5倍的错误数。

但是我仍然产生的质量保证发现的错误是我团队中其他开发人员的两倍。您可能会想到，这会导致非技术人员进行度量标准测量时出现一些问题（请参阅：我的老板）。

我试图指出，我的错误产生率是同龄人的一半（并且修复了两倍），但是当图表显示我产生的错误数目却是两倍时，这是很难的。

那么，如何应对生产率提高会导致错误数量增加这一事实呢？

我认为您在混合担忧。并没有什么对你一面，你需要改变。

生产率是项目完成速度的暗示。项目经理和其他所有人都想知道项目何时交付。更高或更快的生产力意味着我们将看到该项目更快地交付。

错误率与生产力无关，而与项目规模有关。例如，您可能N每Y行代码都有错误。在该度量标准中，没有任何内容可以说明（或在乎！）这些代码行的写入速度。

要将它们结合在一起，如果您具有更高的生产率，是的，您将“看到”更快地编写错误。但是无论如何，您都会遇到这么多错误，因为它与项目的规模有关。

如果有的话，更高的生产力意味着您将在项目结束时有更多的时间来查找这些错误，否则开发人员将更快地找到他们创建的错误。^1个

解决您的问题的更多个人方面。

如果您的老板严格按照所产生的错误数量而不是所产生的错误数量进行检查，那么就应该进行一次培训。没有支持率，创建的错误数量毫无意义。

举个例子，请告诉老板我要加倍薪水。为什么？我绝对没有在您的项目中创建任何bug，因此我是比您优秀的程序员。什么？他将遇到一个问题，就是我没有编写任何代码来使您的项目受益？啊。现在我们已经了解了为什么利率如此重要。

听起来您的团队具有评估每个故事点的错误的指标。如果没有其他问题，那总比用所创建错误的原始数量来衡量。最好的开发人员应该编写更多的错误，因为他们正在编写更多的代码。让老板抛出该图，或者至少在其后抛出另一个系列，以显示有多少故事点（或您衡量的任何商业价值）以及错误的数量。该图将讲述一个更准确的故事。

¹ _{这一特别评论引起了比原计划更多的关注。因此，让我们有点书呆子（惊讶，我知道），然后将我们的注意力重新放在这个问题上。}

_{这个问题的根源在于管理者看错了事情。他们正在查看原始错误总数，而他们应该查看生成率与已完成任务的数量。我们不要着迷于衡量“代码行”或故事点或复杂性等。这不是眼前的问题，那些担忧使我们无法专注于更重要的问题。}

_{如OP的链接中所述，您可以仅根据项目的大小来预测项目中的一定数量的错误。是的，您可以通过不同的开发和测试技术来减少这种错误的数量。再次，这不是这个问题的重点。为了理解这个问题，我们需要接受对于给定规模的项目和开发方法，一旦开发“完成”，我们将看到给定数量的错误。}

_{因此，让我们最后回到一些完全被误解的评论。如果将大小相同的任务分配给两个开发人员，那么生产率较高的开发人员将在另一个任务之前完成他们的任务。因此，生产力更高的开发人员将在开发窗口结束时有更多时间可用。该“额外时间”（与其他开发人员相比）可以用于其他任务，例如处理将通过标准开发过程渗透的缺陷。}

_{我们必须听从OP的话，即他们比其他开发人员生产力更高。这些声明中的任何内容均不表示OP或其他生产效率更高的开发人员在他们的工作中处于低迷状态。指出如果他们在功能上花费更多时间，或者暗示调试不属于该开发时间，则会减少错误，这会漏掉所要求的内容。一些开发人员比其他开发人员速度更快，并且可以产生可比或更高质量的作品。再次，请参阅OP在其问题中列出的链接。}

花一些额外的时间来清洁，抛光和测试代码。仍然会有错误，但是会更少。这需要时间。您的代码输出率将下降，但是您的无错误代码输出将增加，这将提高生产率。因为错误很昂贵。

您能否将代码保留在分支或测试环境中，直到您发现它并捕获更多错误为止？与生产代码中的错误相比，分支中的错误引起的波动通常更少。

但是我并不是完全在挖掘您的断言导致您提出问题。也许你的老板也不是。

我不认为每个编码器都会产生相同的错误率。您的第二个链接实际上是完全不合主题的，因为它比较的是不同的语言，而不是不同的编码人员技能水平。完整代码中提到了一些大样本的测量，它们只是在关注过程而不是编码人员的技能。而且，当他们说顶级编码器生成更多/更好的代码时，部分意味着它的bug更少。取决于应用程序。所以，是的，我认为这是一个不同观点的问题。

最后，如果老板想要更干净的代码，请给他更干净的代码。

我会弯腰当恶魔的拥护者。并不是说我不赞同您的困境，但是，我的同情对您没有帮助。因此，请允许我补充一下菲利普的观点：

您的老板很在乎产品的质量，部分原因是他或她的名字和声誉会受到影响。质量的一部分是感知到的错误数量。如果您出售的真棒钻的钻孔速度是任何其他同类钻的四倍，但故障频率却是其他同类钻的两倍，那么您将有一个不好的声誉。即使可以说演练的效果更好，人们也已经习惯了速度，但是他们会记住故障原因。

事后看来，大多数错误显然是可以预防的。 如果您稍加注意，老板会感到，您可以避免这些问题和任何必要的清理工作。从他的角度来看，这是一件微不足道的，明智的事情，而您对此所做的任何争执都不会起作用，而且会使您看起来很糟。

他无法衡量您的卓越生产力。 您基于可验证的指标要求更高的生产率，那么您的同事对此有何看法？他们是否勉强同意您是一个生产力更高的程序员，还是您自己一个人呢？如果您有其他人来支持您的断言，那么您的观点会更强。

这是观点。现在，您如何“解决”您正在遇到的这种令人沮丧的情况？

放慢一点。 明确提及任何分发您要降低错误率（*）的任务的人，以使他们不会因您的错误摄取而感到惊讶。如果有的话，放慢脚步会因为供应不足而减少分配给您的错误的数量。

_{（*）有之间的差异，一方面，承认存在的漏洞，以你的名字和你努力减轻这一数额，并在另一方面，承认你有太多的虫子您的姓名和应采取行动。}

不要试图说服您的老板，因为它不会起作用。同样，这并不意味着您必须承认自己的观点。您可以提出反对意见并保持意见，而不会忽略他的担忧。因为如果您确实争论了这一点而不能令人满意地证明您的卓越生产力（即使可以），您将有侮辱同事或轻视同事的风险。你不想成为那个人。

假设您将在20％的时间内产生与同事相同的“数量”代码，那么您可以花费4倍的时间真正调试代码并使之完美，这将进一步降低错误率。然后，您可以称自己为优秀的程序员。

最大的问题是为什么您编码的数量是其他编码的5倍，而不是追求质量。这是您的自我决定的事情，还是老板强迫您的事情？

另外，您还需要考虑修复错误的成本。尽早找到它后，您可能仍在代码内部，足以迅速对其进行修复。如果仅在开发一个月后才出现，可能很难找到甚至迫使您更改已编程代码的大部分。

您似乎具有编写代码的技能，并且如果您将重点放在质量而不是速度上，那么可能会很棒。尝试一会儿，我想你会喜欢的。

接下来的问题是获得更好的性能的认可（说钱）。与您的老板交谈，并询问他如何进行，毕竟这是他的公司和金钱，如果他希望您产生更少的错误，他还应该决定以哪种方式发生。

开发人员可以聪明，甚至是天才，都具备理解和单独编码的能力，而不必成为优秀的开发人员。一个好的开发人员可以创造出高质量的作品，并使整个项目变得更好。

我并不是说这是您，而是我工作过的最令人沮丧的程序员之一，编写的代码比团队中任何人都要多，而且我们团队中有优秀的人才。我们使用排名软件跟踪提交情况，因此对于某些人来说，这几乎是一场竞争。他编写了大量代码，留​​下了零文档，难以理解的森林，并且实际上使我自己的一些代码难以理解（我可以自己做，非常感谢！）。最终，他几乎使该项目脱轨，因为他成为了一个单人秀。人们无法跟随他。我们没有作为一个团队同步。几年后，我们实际上重写了他的某些功能，只是为了恢复可维护性。

我想要他做的是放慢脚步，并花更多时间：1）提高代码库的质量2）与团队沟通3）致力于帮助他人并帮助他完成功能/故事的事情4）修复虫子

我不同意用代码行来衡量生产力，但这是一个关键指标。您的代码计数器是否包含注释？如果是这样，那么有一种简单的方法可以在降低“错误率”的同时保持行输出。只需提高您撰写的评论的质量和数量即可。注释很少有bug（尽管可以），通常，我们没有足够质量的注释。我不是在宽容代码膨胀，但注释的行为就像是对迷你代码的审查，它迫使您思考，重构和改进。

尝试启发管理并非一帆风顺。有一个古老的陈词滥调，“你要相信我还是你说谎的眼睛？” 您的老板担心的是错误计数。没有任何合理化可以告诉他们这是可以接受的。风险是它的两倍多。此外，您并不是唯一一个受错误计数影响的人。质量检查有两倍的工作试图识别您的错误，因此管理层将希望您减少这些错误。

最好的解决方案是减少产生的bug数量。管理不仅会更快乐，而且您也会变得更快乐。不会吧 因为我非常确定您所夸耀的表现要比同事好四倍，所以您很乐意说您做到这一点所产生的错误数量甚至比他们少。

如您所说，“……代码中的错误率……倾向于受到编写代码时和编写代码后所使用的过程的影响。” 如果要改变产生错误的速度，则必须更改用于编写代码的过程。

程序员使用生产方法来生产代码，就像流水线使用方法来生产一些批量生产的对象一样。好的，软件行业的做法更像是从树林中发现的分支中敲打小窍门。但是，由于我们要生产机器，因此我们应该采用与大规模生产高速机器相同的严格性和纪律性。

这包括用于批量生产以降低缺陷率的相同技术：根本原因分析，以确定产生错误的原因，并更改错误的过程。或者至少是您在质量检查之前发现的问题。

1. 列出您的错误列表。您可能已经对质量检查人员表示感谢。也可能归类。错误的类型，严重性，将错误注入代码的位置等。

2. 选择最大类别的错误。由于您的交易量很大，因此您应该首先定位该类别。其他类别包括最容易找到和最容易建立的类别。

3. 了解这些错误在代码中的引入位置之后，请研究在该阶段（以及更早的阶段）进行更改以防止这些错误发生，并设法简化该阶段的捕获过程。

4. 确保查看与非编程相关的杂物，它们可能会影响您的工作质量。背景音乐，打扰，进餐时间，工作时间太长而无法休息，饥饿等。

您发现的东西可能会使您走慢一些。另一方面，它可以帮助您更快地生产，因为您无需再加工已经放在后面的东西。实际上，四倍的代码并不能比您的同事好一个数量级，因此改变流程绝对是最好的方法。

将您的目标从产生最多的代码转变为帮助公司最大程度地前进。

由于您似乎有很多同事，还有额外的可用时间，因此，对快速交付功能和错误修复所产生的最大影响就是为您的同事提供帮助。

通过以下方式帮助您的同事

• 使用代码审查来提高代码质量和培训。
• 创建流程自动化，以使其工作更快，生活更轻松。
• 与他们一起编写更好的测试
• 攻击技术代码以改善代码库
• 成为随时可以帮助他人的领导者。
• 编写/改进有助于开发人员生产力的工具
• 如果您有更大的影响力，可以与管理层一起为您的同事提供更好的工具/设备/工作条件。
• 准备并领导有关编写更好代码的教育会议。
• 谦虚

那么，如何应对生产率提高会导致错误数量增加这一事实呢？

您的老板是唯一可以回答您情况的人。与他交谈，指出您的更好比例，然后让他决定。如果他的决定没有道理，那么该是时候以您的思维方式寻找一家公司。

作为专业人员，您应该能够在任何给定的客户条件下工作，只需确保他们了解后果即可。一个不错的错误/故事图表可以帮助您的老板了解如果您花时间生产更少的错误，您的生产力将下降多少。

您还需要考虑以下几点：

• 故事的复杂性，例如简单的getter / setter包装器与统计计算或实时编程甚至实时统计...
• 错误的严重性，是否是文本字段上的小错字或错误的计算结果，程序崩溃
• 修复错误的成本，无论是现在，以后还是以后，或者其他人因您离开而不得不理解您的代码

情况是您的工作速度是普通程序员的四倍，但在给定的时间内犯错的次数是两倍。相对于您所做的工作量，您实际上犯了“平均”错误一样多的错误。

您可能会尝试指出您的工作错误率低，甚至是完成产品的错误（您可以在正常时间的四分之一时间内完成）。大多数老板都会接受这一点。

有些老板不会这样做，因为他们每次都带着“允许”错误的心态工作。然后，您可能会放慢工作节奏，在给定时间内完成两次平均工作量，并犯相同（或更少）的错误，因为您有更多的时间检查工作。

如果老板希望您提高工作质量，则可以提高工作质量。

您应该以零错误为目标，而不是以仅次于最佳程序员的两倍为目标。

您应该告诉老板，他正在使用的度量标准存在很大缺陷。如果您看一下NBA后卫的失误，就会发现他们的人数往往比前锋更高。但这是因为他们更多地处理了球。如果非首发后卫的得分是首发后卫的1/5，并且将球平均翻过3次。一个首发后卫，每场比赛将球转过7次-乍一看，这看起来似乎更糟。但是，如果您将失误数除以上场时间，则很明显，首发后卫根据上场时间会更好。

同样，如果错误的数量除以完成的故事点的数量，则您的数字就更好。因此，这就是我要向您的经理提出的建议。将度量标准更改为错误数量除以已完成的故事点数，或者如果需要每个开发人员的错误总数，则至少为此添加一个新度量标准。但是，由于某些故事要点比其他故事要难得多，也要复杂得多，因此存在并且会存在很多差异，经理也需要考虑到这一点。

我不认为您应该放慢速度。

测量值增加

认为真正重要的是您增加的价值。然后去介绍一下它的粗略（手动）度量：

• 估算您产生的功能的价值
• 减去工资
• 减去错误的估计成本（至少要修复它们的成本）
• 减去您产生的所有其他技术债务的估计成本

剩下的就是您的增值。对于其他人也一样。

这些估算很难，但即使是粗略的估算也可以说明这一点。仅讨论这些估计值的过程对团队和项目都是有用的。

顶级程序员倾向于编写易于调试和理解的非常规则的代码，他们会最大限度地利用可用的工具（静态分析，编译器错误，调试代码）。而且，顶尖的程序员已经通过自己的辛勤经验学习了单元测试的价值。

因此，尽管每行的初始问题数量相同，但问题被更快地排除。