Before any refactoring
- Version control first, if it is not already there. Refactoring without it is editing something irreplaceable.
- The ability to see exactly what a change altered matters more here than anywhere, because you cannot predict what a change will affect.
- Only once that exists does anything else in the thread become sensible.
Finding the seams
The most practical structural advice was to look for modularity rather than to impose it. Somewhere in a tangled codebase there are places where a line can be drawn and a relatively independent piece extracted. They will not be small pieces, because everything is coupled to everything, but the boundaries do exist and become visible when you look for them. Once there are modules you are no longer facing two hundred thousand lines, you are facing several problems of a size a person can hold.
How to introduce the rest
The accepted answer offers a long programme of tooling, practices and reading, and prefaces it with the warning that matters most: introducing all of it to a team at once would not work. Its own framing is that these are guidelines to adopt, adapt or discard depending on circumstances. A comprehensive plan applied comprehensively is how this kind of effort stalls.
The order that emerges
- Make change reversible — version control, and a way to build reliably.
- Make behaviour observable — tests around whatever you are about to touch, before you touch it.
- Find boundaries and extract along them, in pieces small enough to finish.
- Change what you are actually working on rather than launching a rewrite, which is the failure mode this situation invites.