Displacing Legacy Systems | Martin Fowler on Patterns and Methods for Dealing with Legacy Code
ฝัง
- เผยแพร่เมื่อ 13 ส.ค. 2022
- Martin Fowler talks about how to displace legacy code and projects he's working on with patterns of distributed systems. He attempts to answer the question of how do we stop "building the legacy systems of tomorrow"?
This clip was taken from Martin's full Engineering Room episode, which you can see HERE ➡️ • The Fundamentals Of So...
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribepage.com/organis...
_____________________________________________________
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available here ➡️ amzn.to/3DwdwT3
📖 "Continuous Delivery Pipelines" by Dave Farley paperback ➡️
amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
NOTE: If you click on one of these Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you. - วิทยาศาสตร์และเทคโนโลยี
I loved this talk, and I am VERY eager to find more out about this Displacing Legacy Systems book. I've never heard a title that felt more relevant to my day to day professional life and challenges I wrestle with.
What would be meant with "Critical Aggregator", could you give an example in an Enterprise System? THANK YOU for an interesting discussion!
We are all building the legacy system we will hate supporting later.
Code it right because you have to, or suffer the consequences.
Yes. You can avoid having such a big system by establishing boundaries within it and having loose coupling. That is were are lot of developers fail.
If you back up a little bit and you'll see that the first step is to esablish hard boundaries around the legacy aggregator and identify all its "API"s or things it does that's API-like. Once you've identified the box then you can add better "API"s, retire the old ones, and eventually work your way to the desired end state.
I think replacing the critical aggregator first will also give you a much better insight into the core business, and what's actually important. This can be really helpful when rebuilding the other systems afterwards.
The problem with feature parity is that you don't know what the features are, because you don't have any tests, or very low quality tests. But if you did have them, maybe you wouldn't need a replacement anyway, because you can easily refactor as you go.
When my dad was first starting as a programmer, he was writing C applications on AIX to replace COBOL systems. He told me he was thinking about how long it would be before the C code applications were considered legacy and replaced at the time they were deploying.
they are still trying to replace COBOL 😀
amazing
Divide into bite-sized pieces. Schedule changes. Stable phases to regression test after each phase. Get user feedback to invite improvements.
Someone referred to Michael Feather’s book saying that Legacy Code is defined as “code without tests”
I feel like if today we are follow the continuous delivery practices of TDD and automated acceptance testing we will stop building tomorrows legacy systems, at least by Michael Feather’s definition.
I feel like the problem with that critical aggregator was that it was slapped on the system after the fact without tests (that’s why the interfaces are terrible) to me the moment a piece of untested code is committed, that code is Legacy, even if it was committed in the last 60 seconds.
The other thing that really eats at me is when people treat tests after code the same as test before the code, because test after the code completely missed the opportunity to refine the interface which is absolutely critical to long term maintainability.
I guess the only other way I can think of a well designed system that was well factored and well tested still being considered Legacy, would be if the model it was based on does not align with our current understanding of the business domain, but we can’t bring ourselves to replace it, I think this is similar to Dave’s car model example where the central most entity is represented in a very cryptic and symbolic way and it’s so hard to change because it’s so hard to understand… which I think brings us back to the criticality of easy to understand interfaces.
I found Marianne Bellotti books "Kill it with fire" a good reading about legacy system replacement (or better avoid to become legacy)
ooh - yes i saw a system that was still relying on a 20-some year old etl process in an expensive accounting system which no one had figured out how to get rid of - and they were excited becuase new hardware cut it down to only 20 hour run from a 3 day run time.
I'm massively over-simplifying but... To me, a lot of what you're discussing here basically comes down to one thing... decoupling! :)
Yes!
I‘ve experienced replacing legacy systems with blood sweat and tears. We even suceeded once, while that was for the fact that it wasnt rewritten from scratch rather decoupled and only small parts written newly. Was the effort worth it? In my PoV it didn‘t pay off. How will you ever build better system with the same team that let the old one rotten?
I cringe when at the interview I learn that job opening is for the team that will replace legacy system. I dont know why enterprises are so obsessed with it. Is it easier to allocate budget than for maintaining and improving legacy?
Replacing the legacy IT system is only half the story. The legacy Business processes it supports must also be replaced before it can be decommissioned.
This channel has the exact same logo as captain disillusion
You mean it has a ‘C’ and a ‘D’ in it? We created our company logo about 7 years ago, which I think is still after the Captain, but before I’d ever heard of him. So pure chance.
The C and D layout is sorta the same. However, the actual visualization is totally different and unique. I would like to see a collab episode now. LOL th-cam.com/video/tyixMpuGEL8/w-d-xo.html