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

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

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

解决方案

回答

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

回答

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

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

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

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

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

回答

让我们来看看每个选项：

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

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

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

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

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

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

• 只是不做任何重构。

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

• 其他

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

回答

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

回答

• 其他

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