Ask HN: Does every software project require a refactor? It seems every project I've ever been on required an eventual refactoring of the entire codebase. I'm wondering if that's the same for others. |
Ask HN: Does every software project require a refactor? It seems every project I've ever been on required an eventual refactoring of the entire codebase. I'm wondering if that's the same for others. |
There's 3 times to refactor:
1. When you're trying to add a new feature ("prepare").
2. When the new functionality has been added ("tidy").
3. When you're trying to understand the code ("clarify").
The problem is when refactoring is seen as a separate activity from coding. It shouldn't be: it is a _part_ of the coding activity.
If you show me a project that couldn't benefit from a refactor, then you're showing me a project that is effectively EOL sooner or later.
Refactoring is a function of scope and scope violations. When things violate their scope and use global state, the end result is brittle hard to change and even harder to test code.
Many scopes will need to be refactored over time and if elements of a software project are tightly coupled that will mean refactoring the project rather than a module or a component.
As the sins of short term thinking accumulate so too does the daily pain of working on a project until people start to want to factor out their components (in the worst case this is called micro-services), or do a complete re-write.
I think refactoring should always be done with any change to fix scoping problems (removing usage of global state) and a complete refactor is to be reserved for core architecture problems and scaling issues.
The most sane approach is to use something like bazel to start limiting what can depend on what where, which will slowly start to decouple components, likely via forcing dependency injection.
Once you have pressure pushing in the direction of lower complexity (via enforcing limitations) rather than increasing complexity, a lot of problems that seem untenable before become approachable.
Because you phrased it as "eventual refactoring", I'm going to take your question to mean that at some point in the lifecycle the codebase becomes too complex and degraded for a team to work on. At that point, the choice is to either fix it or replace it.
But well-maintained codebases undergo continual refactoring, which counters the decay and trend towards excess complexity. Look at things that have been in use for a long time. The Apache http server has been around since 1995, with only the release 2.0 introducing wide-ranging changes. Linux began in 1991.
In short, if the team, for whatever reason, neglects the effort to maintain the quality of the codebase, then yes, if it continues to be in use, it will need a comprehensive refactoring, or replacement.
https://effectiviology.com/premature-optimization/
IOW, don't waste time in refactoring if it is not imperative for some particular reason.
But like any rule, if we're talking specifics, there are exceptions. Scripts you use occasionally do not need developer time committed to iterating on. They can technically be improved, and refactoring them would likely lead to benefits, but they don't require it. There is nuance.