Legacy Seam

martinfowler.com

18 points·ingve··6 comments

If there was a book that had a transformative change on how I tackled legacy projects, "Working Effectively with Legacy Code" was it. I can't recommend it enough. The book is packed with pragmatic gems that help slowly and steadily turn any legacy software project into a modern codebase.

I found it suggests too much maintanence on the legacy system and not enough refactoring.

Legacy systems shouldn't be patched with one line changes forever, you need to evolve them over time to become the modern system you want. You're never going to get "the big rewrite", or at least I'd be concerned if you did.

> I found it suggests too much maintanence on the legacy system and not enough refactoring.

I don't think this is true at all. The books starts by defining legacy systems as projects without any automated test coverage, and proceeds to dedicate virtually the whole book to focus on the problem of gradually adding tests, starting with vice tests, in a way that minimizes changes and therefore the chance of introducing regressions when refactoring code.

The whole point of the book is to help developers refactor legacy projects until they cease to be legacy projects.

If anything, the whole book is dedicated to refactoring, but following a non-trivial path that eliminates the chance of introducing regressions. It's very odd that your personal take is maintenance when none of that is covered by he book at all.

Fowler has a longer article on the topic of modernizing legacy systems that discussed this. I found it worth a read, even though it appears to be in flux: https://martinfowler.com/articles/patterns-legacy-displaceme...

I find the strangler pattern handy when dealing with legacy code

https://www.redhat.com/architect/pros-and-cons-strangler-arc...

So this is basically advocating for dependency injection?

Reply on news.ycombinator.com