问scrum和重构

EN

我认为，对于技术债务重构来说，维护代码的努力/成本影响与重构代码的成本一样高，甚至更高，以提高质量或更好/更好地工作-特别是为了使其具有更高的可维护性，这是一个公平的案例。

例句:如果软件出了太多问题，你可能会失去客户或金钱，你会迅速采取行动修复它。有些人可能会认为这是它自己的业务需求，但它通常不会放在中小型开发项目的前沿和中心，而是专注于创建应用程序的技术细节，而不是应用程序质量对底线的影响。

我认为你可能在谈论大规模重构，而不是你在整个红-绿-重构周期中所做的持续重构。

我的方法是这样的，如果重构一个旧功能可以更容易地添加一个新功能，那么就去做吧。但在某些方面你是对的，如果在特定单元上没有改变的压力(即它完全完成了，不会再改变，也不会影响其他模块)，那么就没有重构的实际需要。然而，我很少发现一个模块是完全定稿的。

如果你可以通过识别当前代码集的问题/风险来证明它是完成其他任务的过程的一部分，并且这是一个更好的最终结果，那么就去做吧。但不要过于热衷于破坏时间表/预算。