跟踪Bug数据库中的重构

Question

假设您在某个地方工作，对源代码的每一项更改都必须与bug报告或特性请求相关联，而且没有办法对该策略进行改革。在这样的环境中，处理代码重构的最佳方法是什么(即改进代码但不修复bug或添加特性的更改)？

bug-report/feature-request.

• Just

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

• 编写特性请求并将重构与其关联。

• 在处理与关联的代码时偷偷地插入了重构。

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

Answer 1

我投票赞成“偷偷摸摸的重构”方法，我相信，这是重构的方式之一。仅仅为了“清理代码”而重构可能是个坏主意。这意味着你在无缘无故地做出改变。根据定义，重构是在没有修复bug或添加特性的情况下进行修改的。如果您遵循KISS原则，那么任何新特性都至少需要进行一些重构，因为您并没有真正考虑如何使第一次使用最可扩展的系统成为可能。

Answer 2

我们的工作方式是:必须有一个很好的理由来重构代码，否则为什么？

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

如果要使产品变得更快，创建一个更快的“xyz”特性请求，并将更改与其关联起来--那么客户就会看到您正在改进产品。

如果要设计一个bug，就记录这个bug。

值得注意的是，在我的环境中，这个政策是无法执行的。但是聪明的管理人员可以得到更改的报告，如果他们在提交文本中没有bug\请求引用，就会进行跟踪。

Answer 3

如果您正在处理一个代码块，在大多数情况下，这是因为有一个bug修复程序或新特性需要更改该代码块，并且重构要么是在更改之前进行，以使更改更容易，要么是在更改之后来清理结果。在这两种情况下，您都可以将重构与bug修复或特性关联起来。