Very carefully. But seriously, check out the book "Working Effectively With Legacy Code" by Feathers. It has helped me tremendously in multiple refactorings.
His thesis is that Legacy Code is code without tests. So to make it not Legacy you need to add tests then refactor safely. Then he explains the very complex patterns that can arise and how to deal with them.
Thanks for the recommendation! Exactly what I was looking for. Yup, the problem is that large chunks of the code are useless and must be removed, but I don't really want to write tests on those. Other parts have to be decoupled and removed and I end up needing to write end to end tests.
First, getting this right without unplanned downtime can be hard to achieve and as well as lots of diligence it also really requires the right level of general application architecture plus hands on engineering experience.
The general process is assessment and understanding the system, refactoring and improving code without program changes, and re-achitecting key pieces to enable the testing, then getting test coverage to where it gives you the required confidence to make the change.
Great idea! I really like it, I have worked in a few places where that happened as well. Can we collaborate a little bit more on what specific you are looking for - my contact details are on my blog (link is in my profile). Hope to hear back from you.
Comments
How can I refactor a monolithic codebase when every change breaks everything?
Very carefully. But seriously, check out the book "Working Effectively With Legacy Code" by Feathers. It has helped me tremendously in multiple refactorings.
His thesis is that Legacy Code is code without tests. So to make it not Legacy you need to add tests then refactor safely. Then he explains the very complex patterns that can arise and how to deal with them.
This book is one of a few that changed my career.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
Thanks for the recommendation! Exactly what I was looking for. Yup, the problem is that large chunks of the code are useless and must be removed, but I don't really want to write tests on those. Other parts have to be decoupled and removed and I end up needing to write end to end tests.
First, getting this right without unplanned downtime can be hard to achieve and as well as lots of diligence it also really requires the right level of general application architecture plus hands on engineering experience.
The general process is assessment and understanding the system, refactoring and improving code without program changes, and re-achitecting key pieces to enable the testing, then getting test coverage to where it gives you the required confidence to make the change.
Great idea! I really like it, I have worked in a few places where that happened as well. Can we collaborate a little bit more on what specific you are looking for - my contact details are on my blog (link is in my profile). Hope to hear back from you.
First write tests without touching existing code. Once tests are complete, do refactor.
For context, it's Android, and it'd doing weird threading stuff that makes tests crash.