如何确定“代码改进”的优先级和严重性？

我们的错误跟踪系统中有“优先级”和“严重性”字段。我们将严重性定义为“它如何影响用户”，将优先级定义为“它如何影响产品”。

我的问题是关于如何按照严重性和优先级对“代码改进”任务进行分类。假设改进不会改变任何行为，而是使其成为“更好的代码”。我们预计总体上将获得长期的维护改进，但是很难量化。

当我们将定义用于优先级和严重性时，除非您在图片中引入一些难以预测的长期收益，否则代码改进将使这两个值均达到最低值。因此，这意味着代码改进是一项艰巨的任务，切勿尝试。

但是，我认为不断改进和重构代码至关重要，因为：

• 软件开发本身就是一个持续的学习过程，如果不对代码进行改进，就无法做得更好。
• 团队应该为自己的代码感到自豪。
• 未来的维护将花费更少的时间，从长远来看，节省的费用将是可观的。

还是您认为不应创建此类任务，而只能在“按需”，“与错误关联时”执行此类改进？即使它与错误相关联，这也不是代码审查的讨论重点，例如“为什么您要在结构上进行如此大的改变？”。

通常，我不喜欢将“代码改进”活动视为单独的可分配任务，因为代码改进本身永远不会直接带您接近完成用户案例或需求。这就是为什么代码改进任务将始终具有如此低的优先级，以至于它们从未得到分配。

我认为代码改进是一个常数，每个开发人员都应该像在键盘上一样自然地进行代码改进。我将其纳入任何任务的估计中。如果我的任务涉及我接触很长时间未查看的类或某些源代码，那么我将假定一些清洁工作可能是有条理的，并相应地增加了我的估计。

最好的情况是，我尽早完成任务，并可以利用剩余时间来改进代码甚至设计。最坏的情况是，任务花费的时间比预期的要长得多，但是我有多余的时间作为缓冲。

如果要重构代码，请根据您的定义（即“它如何影响产品”）设置任务的优先级。某些重构不会对产品造成太大影响，而某些重构会影响产品，具体取决于所需工作的范围。设置较高的优先级将指示在重构完成后需要进行更多测试，以确保未发生任何意外情况。

您可能还想在错误跟踪系统中引入一个新类别，以将这些类型的任务归类为“重构”任务。这样，您将知道如何解释优先级值。也就是说，更高的优先级意味着更大的影响，因此需要更多的测试。

缺少的是验证您对现有代码的假设：如果我们改进代码，则可以减少时间并节省大量资金。这是化妆品还是有严重问题？

检查您的调试和增强估计。如果他们花费的时间更长，并且有关于必须首先重构代码或清理代码的持续注释，那可能是您的最佳选择。然后，您可以将您的代码库标识为：良好，需要进行少量的返工或需要进行认真的重构。

所有这些都是相对的。当有些客户想要更多功能并愿意立即为计费时间付费时，很难给予如此高的优先级。

有趣的问题。

我认为您必须估计更改可能影响多少行代码和多少个模块。

也许您可以看看有多少单元测试会因更改而中断。这可能意味着首先尝试在分支机构中进行更改以获得想法。

然后为这些匹配级别的优先级和严重性设置阈值。

您还应该考虑到有很多测试人员需要参与测试。如果更改涉及应用程序的较大表面积，则可能需要重新审查许多系统测试。

让我们从两个假设开始。

1. 对于每个新故事，您都将尽自己最大的能力编写代码，这可能与您团队的常识相提并论。
2. 每当您的故事改变了现有代码的功能时，便会在实施新故事的过程中使用对系统的新知识和更好的技能来改进代码。

给定这两个假设，就无需进行明确的“代码改进”工作。在编写系统时，您的代码将得到改善。这意味着并非所有代码都符合您最新和最严格的可维护性标准，但是“如果没有破坏，就不要修复它”。我认为重构代码不需要像添加不需要的可见功能那样被更改为“镀金”。如果代码以某种方式被破坏，则编写一个失败的有效测试。记录错误；然后重构以解决该错误。

我会从敏捷运动中窃取投票权：

输入错误，粗略猜测其严重性和优先级，

然后，每天，每周或每月审查所有新错误，并对它们的等级进行投票。理想情况下，您在与最终用户进行的Sprint计划会议期间执行此操作。然后，您也可以同时讨论下一个功能，并保持乐观态度，