Tracking Refactorings in a Bug Database假设您在某个地方工作，在此地方，对源代码的每次更改都必须与错误报告或功能请求相关联，并且无法对该政策进行改革。 在这样的环境中，处理代码重构的最佳方法是什么(即，改进代码但不修复错误或添加功能的更改)？
请注意，所有错误报告和功能描述将对管理人员和客户可见。 我赞成"偷偷摸摸的重构"方法，我认为这是首先要进行重构的方式。仅仅为了"清理代码"而进行重构可能不是一个好主意。这意味着您没有任何正当理由进行更改。根据定义，重构是指修改，而无意修复错误或添加功能。如果您遵循KISS原则，那么任何新功能都将至少需要进行一些重构，因为您并没有真正在第一次考虑如何使最可扩展的系统成为可能。 如果您正在处理一段代码，在大多数情况下，这是因为有一个错误修复程序或一项新功能要求更改该代码块，并且重构是在更改之前进行，以使其更容易，或者更改后整理结果。无论哪种情况，都可以将重构与该错误修复程序或功能相关联。 我们的工作方式是：必须有充分的理由来重构代码，否则为什么？ 如果原因是允许另一个功能使用相同的代码，则将更改与另一个功能的请求关联。 如果要加快速度，请创建功能请求以更快地" xyz"并将其与更改相关联-然后客户会看到您正在改进产品。 如果要设计一个错误，请记录该错误。 值得注意的是，在我的环境中，该策略无法执行。但是，聪明的经理可以获取更改报告，如果他们在提交文本中没有错误\请求引用，则会对其进行跟踪。
如果您在一个有这种呆板(荒唐)政策的地方工作，最好的解决方案就是找另一份工作！ 让我们来看看每个选项：
如果您认为原始代码构成安全风险或崩溃或不稳定的可能性。编写一个小错误报告，概述危险，然后加以解决。
根据功能请求，可能更难编写反应堆代码。但是您可以使用有效的功能请求来执行此操作，从而将我引向下一点...
如果存在有效的错误或功能，请声明必须稍微更改功能x才能修复错误或添加功能。
这似乎表明不允许通过改进应用程序进行自我开发。应该允许开发人员，如果不能，则鼓励他们探索新技术。
也许您可以在相关会议上讨论您的改进，并给出令人信服的理由进行更改。然后，至少您将需要管理层支持更改，而不必通过其他方法来偷偷摸摸地编写代码。 |
