You open a file to add a simple configuration flag, and three hours later you're tracing a state mutation across six undocumented helper classes. The developer who wrote it left three years ago, and there are no tests. You have two choices: refactor the mess, or throw it away and rewrite it.
Early in your career, the goal is just getting the feature to ship. You jam the new requirement into an existing function, push the code, and tell yourself the resulting mess isn't your fault - the file was already terrible.
Eventually, you run git blame on a file that gives you nightmares, and you realize you wrote it 18 months ago.
You can't rewrite your way out of bad habits. If you start a greenfield rewrite without fixing how you write code, you will just build the exact same tar pit in a newer framework.
You don't need to memorize academic definitions of SOLID principles or Clean Code to fix a system; you need to stop writing controllers that parse HTTP requests, execute raw SQL, and trigger email notifications all in the same 500-line method. You have to isolate your business logic from your infrastructure.
Before you change anything, you need a testing strategy. Write a unit test for the function you hate most and count how many dependencies you have to mock. If the setup takes fifty lines, your boundaries are wrong. You have to lock in the current behavior before you start tearing the architecture apart.
You also need a baseline. Run SonarQube against the repository to map out the cyclical dependencies and find the highest-risk files. Don't use it to chase arbitrary test coverage percentages; use it to identify the exact classes that are paralyzing your pipeline so you know where to start.
A new programming language won't fix the boundaries you never drew. Write the tests first, whether you are refactoring in place or starting from scratch.
We look at how to decide whether to refactor or rewrite in part two of this series.