5

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

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

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

4

5 回答 5

7

我投票赞成“重构潜入”方法，我相信，重构首先就是要完成的。仅仅为了“清理代码”而进行重构可能是个坏主意。这意味着您在没有真正原因的情况下进行更改。重构，顾名思义，就是在不修复错误或添加特性的情况下进行修改。如果您遵循 KISS 原则，那么任何新功能都需要至少进行一些重构，因为您并没有真正考虑如何在第一次就使最可扩展的系统成为可能。

于 2008-09-10T14:53:43.480 回答
2

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

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

如果是为了让某些东西变得更快，请创建一个更快的“xyz”功能请求并将更改与之相关联——然后客户就会看到你正在改进产品。

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

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

于 2008-09-10T14:56:08.497 回答
2

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

于 2008-09-10T15:09:32.507 回答
0

让我们看看每个选项：

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

如果您认为，在您看来，原始代码会带来安全风险或崩溃或不稳定的可能性。写一个小错误报告，概述危险，然后修复它。

  • 编写一个功能请求并将重构与它相关联。

根据功能请求来反应代码可能更难。但是您可以使用有效的功能请求来执行此操作，这会引导我进入下一点......

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

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

  • 只是不要进行任何重构。

这似乎表明不允许通过改进应用程序进行自我开发。应允许开发人员（如果不允许）鼓励探索新技术和新技术。

  • 其他

或许你可以在相关会议上讨论你的改进，给出令人信服的理由说明为什么要做出改变。然后，至少您将获得管理层对更改的支持，而不必通过另一种方法潜入代码。

于 2008-09-10T14:59:37.163 回答
0
  • 其他

如果你在一个有那种僵化（和荒谬）政策的地方工作，最好的解决办法就是找另一份工作！

于 2008-09-10T16:05:41.450 回答