跟踪Bug数据库中的重构

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

如果您正在处理一个代码块,在大多数情况下,这是因为有一个错误修复或新功能需要更改该代码块,而重构要么在更改之前进行,以使更改更容易,要么在更改之后进行,以整理结果。在这两种情况下,您都可以将重构与错误修复或功能关联起来。

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

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

如果要使某个东西更快,请为更快的“xyz”创建一个功能请求,并将更改与之关联——然后客户会看到您正在改进产品。

如果要设计一个bug,请记录这个bug。

值得注意的是,在我的环境中,政策是无法执行的。但是聪明的管理者可以得到变更的报告,如果他们在提交文本中没有bug\request引用,就可以跟进。

让我们看看每个选项:

• 写一个bug报告并将重构与之关联。

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

• 编写一个特性请求并将重构与之关联。

基于特性请求来反应代码可能会比较困难。但您可以使用有效的功能请求来完成这一点,这将引导我进入下一个阶段…

• 在处理与bug报告/功能请求相关联的代码时,偷偷进入重构。

如果有一个有效的bug或特性,说明必须稍微更改函数x才能修复bug或添加特性。

• 只是不要做任何重构。

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

• 其他

也许你可以在相关的会议上讨论你的改进,给出令人信服的理由来解释为什么应该做出这些改变。然后,至少您将获得对更改的管理支持,而不必通过另一个方法偷偷地输入代码。

• 其他

如果你在一个有着这种不灵活(荒谬)政策的地方工作,最好的解决办法就是找到另一份工作!