Refactoring/Rewrites is the MOST rewarding task that can be achieved with both legacy and new code. I do it from the start of my career (when I don't even know the name of it).
And that include, regulary, rewriting to different langs (like, for example FoxPro -> C#, C# -> Python -> F# -> Swift (aborted) -> Rust (noob) -> Rust (now I know rust, almost!) Exits a lot of FUD against this. Is risky? Is hard? Can be messed up? Everything is staked against you? Yep LIKE ANY OTHER CODE ACTIVITY.
----
Things that help in make this a success (assuming, of course, an average, half-decent developer. But I have done it when I not even know anything, so who knows if it work?):
CRITICAL:
- Have source control
- Have a task manager (mine: pivotal)
- Split stuff in small tasks (couple hours max)
- Priorize to know the data(schemas), the business REAL priorities (because all the time, everything will be declared of imperative importance). The code? Less so. If the code is good then you are not considering this at all.
- This can be done in the small or in the large. So, a full rewrite can be totally done in hours. If all is so tangled this is not true, then the code is beyond salvation, REWRITE.
Nice:
- If possible, deployable code in one go (of the old code)
- The database (or data in general) is kind of easy to grasp (if not, all is a mess, REWRITE). With a good database, rewrite is far more profitable than refactoring messy logic.
- Have good test that can be used to validate it? Great. I rarely have that luxury.
To become good:
- Rewrite/Refactor is a muscle. The more you do it, the better you become.
- Do A LOT of MICRO side-projects or experiments. Trash them, rewrite them, explore them. Make your mind used to it (note: this is not "ruin my life, only code yo!", is to start a major idea with a micro side project before commit bigly)
Everyone know the second time your code is better. Imagine if you do 5 rewrite in successions. That code will be celestial!
- Be confident in being able to read code. Read code. And read more. Much more if is a new lang.
- Ask question, and ask the same question, differently.
- Pick a project that you can do in your sleep (mine: Pseudo micro ORMS) and start with that when new lang or framework. In a side project. Must be of small size (few files, at most)
- If change lang, framework, be aware that some are BETTER than others. Learn to know why and when start using it.
- Dedicate a few minutes learning useful stuff.
- Do the HARDEST stuff first, at least, a significant piece of it. If the hard is done, the rest is easier!
- Have a solid selection of companion tools that you RARELY need to change (mine: Sqlite, Postgres, nginx, ubuntu (deploy))
The MORE messed up, the BIGGER is the payoff:
- Not have tests or are all useless? Start writing test and all is tangled? Rewrite
- Like a stupid idiot you are 4 months into a refactoring (doing stuff properly and all) and all paths lead to doom? Rewrite (you probably feel it 3 months ago. Idiot me)
- You testing (manually, auto, whatever) take X times than write code? Rewrite
- The customer is on fire, nothing work, all things are delayed? Rewrite
- Everyone in the path of requirements are even more lost than you? Rewrite
---
Surely exist some stuff that is conveniently ignored in this list: Have a customer/team that accept the rewrite.
Look, if the customers/boss/team is THAT bad, then NOT MATTER what you do, you ARE SCREWD.
But I'm lucky, and have worked in situations with serious trouble (but decent humans around, even if can't help much and I must figure a lot on my own) have tell me that people are more accepting of rewrites than some could think. Even delayed projects can be tolerated if exist a good flow of improvements.
P.D: This is my experience in my sector, and the few I have done in a mid-size startup...