4 ms·

Refactoring is generally not about the code style, or changing the design for its own sake. Refactoring happens because the model of the world that the softwar

Refactoring is generally not about the code style, or changing the design for its own sake. Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. That's when refactoring is needed. Also. Tech debt is usually (not always) the marginal cost of the next feature. If new features cost X, and engineers are convinced that features could cost much less if the software was organised differently, then it might be useful to calculate the cost of a refactor.

corethree 3y ago
>Refactoring happens because the model of the world that the software works with has changed since the software has been implemented. Maybe the way users and roles are represented was kinda OK 5 years ago, but the world (== business environment, understanding, requirements) has changed since. So the code that has been OK 5 years ago is painfully mismatched with the present. Totally agreed. This is a practical reason for it. But much of refactoring doesn't happen because of this. The article says you should refactor all the time for "better" code. It's not talking about your use case where you have to update dependencies, security features and things like that.