跟踪错误数据库中的重构

Question

假设您在某个地方工作，对源代码的每次更改都必须与错误报告或功能请求相关联，并且无法对该策略进行改革。在这样的环境中，处理代码重构（即改进代码但不修复错误或添加功能的更改）的最佳方法是什么？

• 编写错误报告并将重构与其相关联。
• 编写功能请求并将重构与其相关联。
• 在处理与错误报告/功能请求相关的代码时潜入重构。
• 只是不要进行任何重构。
• 其他

请注意，经理和客户都可以看到所有错误报告和功能描述。

Answer 1

我投票支持“潜入重构”方法，我相信这就是重构最初应该进行的方式。仅仅为了“清理代码”而进行重构可能是个坏主意。这意味着您没有真正的理由进行更改。根据定义，重构是修改，而不是修复错误或添加功能。如果您遵循 KISS 原则，那么任何新功能都将至少需要一些重构，因为您并没有真正考虑如何在第一次时构建最具可扩展性的系统。

Answer 2

如果您正在处理代码块，在大多数情况下，这是因为存在错误修复或新功能需要更改该代码块，并且重构要么在更改之前进行，以便使其更容易，要么更改后整理结果。在任何一种情况下，您都可以将重构与该错误修复或功能相关联。

Answer 3

我们的工作方式是：重构代码一定有充分的理由，否则为什么呢？

如果原因是允许其他功能使用相同的代码，请将更改与其他功能的请求相关联。

如果是为了让某些东西更快，请创建更快的“xyz”功能请求并将更改与其相关联 - 然后客户会看到您正在改进产品。

如果要设计出错误，请记录该错误。

值得注意的是，在我的环境中，该策略无法执行。但聪明的管理者可以获得更改报告，如果他们在提交文本中没有错误\请求引用，则会跟进。

Answer 4

让我们看一下每个选项：

• 编写错误报告并将重构与其相关联。

如果您认为原始代码存在安全风险或潜在的崩溃或不稳定。写一份小错误报告，概述危险，然后修复它。

• 编写功能请求并将重构与其相关联。

根据功能请求来反应代码可能会更困难。但是您可以使用有效的功能请求来执行此操作，这将引导我进入下一点......

• 在处理与错误报告/功能请求相关的代码时潜入重构。

如果存在有效的错误或功能，请说明必须稍微更改函数 x 才能修复错误或添加功能。

• 只是不要进行任何重构。

这似乎表明通过改进应用程序进行自我开发是不允许的。如果没有的话，应该允许开发人员探索新技术和新工艺。

• 其他

也许你可以在相关会议上讨论你的改进，给出令人信服的理由为什么应该做出改变。那么至少您将得到管理层支持更改，而不必通过其他方法潜入代码。

Answer 5

• 其他

如果你在一个有这种不灵活（而且荒谬）政策的地方工作，最好的解决办法就是另找一份工作！