在错误数据库中跟踪重构

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

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

请注意，所有错误报告和功能描述将对管理人员和客户可见。

---

我赞成"偷偷摸摸的重构"方法，我认为这是首先要进行重构的方式。仅仅为了"清理代码"而进行重构可能不是一个好主意。这意味着您没有任何正当理由进行更改。根据定义，重构是指修改，而无意修复错误或添加功能。如果您遵循KISS原则，那么任何新功能都将至少需要进行一些重构，因为您并没有真正在第一次考虑如何使最可扩展的系统成为可能。

---

如果您正在处理一段代码，在大多数情况下，这是因为有一个错误修复程序或一项新功能要求更改该代码块，并且重构是在更改之前进行，以使其更容易，或者更改后整理结果。无论哪种情况，都可以将重构与该错误修复程序或功能相关联。

---

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

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

如果要加快速度，请创建功能请求以更快地" xyz"并将其与更改相关联-然后客户会看到您正在改进产品。

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

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

---

• 其他

如果您在一个有这种呆板(荒唐)政策的地方工作，最好的解决方案就是找另一份工作！

---

让我们来看看每个选项：

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

如果您认为原始代码构成安全风险或崩溃或不稳定的可能性。编写一个小错误报告，概述危险，然后加以解决。

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

根据功能请求，可能更难编写反应堆代码。但是您可以使用有效的功能请求来执行此操作，从而将我引向下一点...

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

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

• 只是不做任何重构。

这似乎表明不允许通过改进应用程序进行自我开发。应该允许开发人员，如果不能，则鼓励他们探索新技术。

• 其他

也许您可以在相关会议上讨论您的改进，并给出令人信服的理由进行更改。然后，至少您将需要管理层支持更改，而不必通过其他方法来偷偷摸摸地编写代码。

---