跟踪Bug数据库中的重构

Question

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

• 编写错误报告并将重构与其关联。
• 编写功能请求并将重构与其关联。
• 在处理与错误报告/功能请求相关联的代码时隐藏重构。
• 不要做任何重构。
• 其他

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

Answer 1

我投票支持“偷偷摸摸的重构”方法，我相信，重构的方式首先应该完成。为了“清理代码”而重构可能是一个坏主意。这意味着你没有真正的理由进行更改。根据定义，重构是在不修复错误或添加功能的情况下修改它。如果您遵循KISS原则，任何新功能至少需要一些重构，因为您并没有真正考虑如何在第一次使最可扩展的系统成为可能。

Answer 2

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

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

如果要更快地制作某些内容，请为更快的'xyz'创建功能请求并将更改与之相关联 - 然后客户会看到您正在改进产品。

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

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

Answer 3

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

Answer 4

让我们看看每个选项：

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

如果您认为原始代码存在安全风险或可能导致崩溃或不稳定。写一个小错误报告，概述危险，然后解决它。

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

根据功能请求，反应堆代码可能更难。但是你可以使用有效的功能请求来实现这一点，这将引导我进入下一个点......

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

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

• 不要做任何重构。

这似乎表明不允许通过改进应用程序来实现自我发展。如果没有，开发人员应该被允许鼓励探索新的技术和技术。

• 其他

也许您可以在相关会议上讨论您的改进，给出令人信服的理由，说明为什么要进行更改。那么至少你将有管理层支持改变，而不必通过另一种方法偷偷摸摸代码。

Answer 5

• 其他

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