跟踪Bug数据库中的重构

Question

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

• 编写错误报告并将重构与之关联起来.
• 编写功能请求并将重构与其关联.
• 在处理与错误报告/功能请求相关联的代码时,在重构中潜行.
• 只是不要做任何重构.
• 其他

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

Answer 1

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