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

Question

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

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

当我们使用优先级和严重性的定义时，代码改进会得到两者的最低值，除非您在图中引入一些难以预测的长期效益。因此，这意味着代码改进是一项烦琐的任务，永远不应该尝试。

但是，我认为不断改进和重构代码是很残酷的，因为：

• 软件开发本身就是一个不断学习的过程，如果不改进代码，您就无法更好地完成它。
• 团队应该为他们的代码感到骄傲。
• 未来的维护将花费较少的时间，从长远来看，节省的费用将是可观的。

或者你认为永远不应该创建这样的任务，而这样的改进仅仅是“按需”执行的，“当与bug关联时”？即使它与bug相关，这难道不是代码评审的讨论点吗?例如，“您为什么要对结构进行如此剧烈的更改？”

Answer 1

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

我认为代码改进是一个常数，每个开发人员都应该像在键盘上键入一样自然地做一些事情。我把它考虑到我对任何任务的估计中。如果我的任务涉及到一个类或一些已经很长时间没有被研究过的源代码，那么我将假设一些看门人的工作可能是有序的，并相应地增加我的估计。

最好的情况下，我会提前完成任务，并且可以使用剩余的时间来改进代码，甚至设计。最坏的情况下，任务花费的时间比预期的要长得多，但我有额外的时间作为缓冲区。

Answer 2

如果您想重构您的代码，请根据您的定义(即“它如何影响产品”)设置任务的优先级。根据所需工作的范围，有些重构不会对产品产生太大影响，而有些则会影响产品。设置更高的优先级将意味着在重构完成后需要进行更多的测试，以确保没有意外发生。

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

Answer 3

缺少的是验证您对现有代码的假设:如果我们改进代码，可以获得更少的时间和大量的节省。这是化妆品还是有严重的问题？

检查您的调试和增强估计。如果他们需要更长的时间，并且有关于必须首先重构代码或清理代码的持续评论，这可能是您的最佳度量。然后，您可以将您的代码库标识为:很好，需要少量的重新工作或需要进行严肃的重构。

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