Learn how to refactor an existing codebase as you go using specific techniques to incrementally make it easier to maintain.
Sign up for my newsletter to get a free chapter preview on performing incremental refactorings so you can stop and ship at any time.
Or buy it now if you're already convinced!
Every week it's the same story: you have to change that codebase. Maybe it's to fix a bug, to tweak some behavior, or to implement a new shiny feature.
You didn't write that code!
It's an undocumented tangled mess. You would love to refactor this code before you change it. But it has no test! Without tests, you're afraid to break something while you refactor—you got burned already, not twice!
OK, so you could start by writing the tests. But you're worried that won't have enough time to meet "the deadline" that was imposed on you…
And there you are: paralyzed because you don't know where to start. Should you begin a huge cleanup and risk the deadline? How can you add tests on a code that was definitely not written to be testable?!
You try to unwind the mess and the string just keeps on coming.
It is getting better, but you can't stop because it is not working yet… but it's 9pm now, and your loved ones are mad at you! 😡
You know what happens next…
You stop trying to make sense out of this mayhem. You just Make It Work™. It's not pretty. It's not that bad. There are worse hacks in this spaghetti! You get the job done while making the code worse.
You wish you could just start everything over, but you can't. No time, no budget.
You are not proud of this code—how could you? But you're getting used to it. Clients are pressing you for "more features" and your colleagues don't seem to care.
Your boss doesn't understand why it takes you longer and longer to finish tasks. You raised the point already, but deadlines are still too short and the focus is always on cost and time. No-one cares that your eyes bleed while reading the code!
You know what would be great? Working with clean, well-tested code. That would be a breeze to work with…
But this codebase is a minefield. How could you stop making it worse when it would take YEARS to address the Technical Debt!?
What if there was a way to refactor the code AND consistently meeting the deadlines?
Imagine you could refactor as you go, steadily turning the codebase into a testable, easy-to-read, well-designed system! 🌱
If you know the moves, you can give your code first aid that will stop its hemorrhage. How proud and relieved would you feel as you put it back into a healthier shape?
Sure, this system you're maintaining is broken everywhere. It seems to work, but it only really survives with heavy machinery and clever hacks. It looks like it would better to let it go and build a fresh one instead…
But what if you knew the techniques to rescue it?
Regardless of the state of your codebase, you will always know where to start. Consistently applying the proper techniques, you can stop the carnage and avoid a costly rewrite.
Most of all, you will keep shipping bug fixes and features as you go.
You don't need to ask permission to refactor when you can do it on the fly!
Refactoring would become second nature to you. Your reflexes will make you clean up Legacy Code in no time! You will consistently meet clients' expectations and inspire your peers.
You can start making this codebase a better place the very next time you touch it. ✨
When you have short deadlines, trying to refactor the code is a risky move… unless you know exactly what you're doing.
I've built a toolbox of techniques that will help you get your Legacy Code under control. These are the tricks that work the best for me when working with a real-life codebase, with missing tests and short deadlines—sounds familiar, right?
These 14 moves will help you:
It's an e-book of approximately 200 pages. It comes with a light and a dark theme.
It's a collection of 14 techniques to work with Legacy Code:
Each technique comes with concrete examples for when and how to use it. On top of that, I detail why it works: the philosophy behind each approach, so you can adapt to any situation.
Finally, the kit comes with a few printable sheets you can keep next to you.
Go through the book to get a sense of what's inside.
Then, keep it within easy reach. The next time you touch your legacy codebase, pick a technique and try it. Soon enough, you'll make that code a better place!
Working with your codebase should become an exciting challenge again: how much can you improve now? What will you leave for later? How can you make this code a little bit better AND deliver value now? Can you feel the code becoming easier to work with?
Finally, you'll start turning a spaghetti codebase into a testable, easy-to-read, well-designed system — while shipping features and fixes 😉🍷
… and these precious skills will make you VERY valuable. 💎
14 techniques to quickly and safely rescue a codebase
PDF, ePub, and Kindle formats
~200 pages of content
Light & Dark themes
3 printable cheatsheets
1 printable exercise sheet
🇫🇷 La version Française du guide
Hey, I'm Nicolas Carlo 👋
I have been a web developer, freelancer, consultant, and Tech Lead. Every single time, I had to work with existing code I was afraid to change. I realized that Legacy Code runs the world… but developers aren't prepared to maintain it!
I collect tips & tricks to deal with legacy systems on understandlegacycode.com
I also develop open-source tools to help developers work with legacy codebases.
The book is 201 pages long.
When you purchase, you get a zip file containing PDF, EPUB, and MOBI formats. You also get printable cheat sheets to practice the techniques.
11 techniques are valid regardless of the language you are working with. 3 of them have better tooling support in statically typed languages.
Sure! It's not automated yet but reach me out at firstname.lastname@example.org and I'll create a PayPal invoice for you.
Sure. I offer a 100% no-questions-asked money-back guarantee.
My goal is to help you work with Legacy codebases. I wish this book saves you time, money, and sanity.
You can buy multiple copies of the guide. It's a way to tell me "thank you Nicolas", and I appreciate that!
Now, there is nothing preventing you from sharing the guide with your colleagues. Maybe also your client/employer could cover the cost as a professional expense.
Send me an email at email@example.com