Taming legacy (on a live project)
Almost every project accumulates legacy code over time, this is a story of what we learned and how we’ve put it under control on one large,
Legacy is a wide term which covers more than that spaghetti code that brilliantly mixes raw sql and html and which you’ve wrote 10 years ago. Michael Feathers defines legacy code it as “code without tests” and that’s certainly true, but it goes deeper than that. Open source library that works just fine and is written beautifully but whose active development is about to be stopped - that’s legacy, clean architecture ideas that don’t fit well into developed system architecture anymore - those are legacy too etc. Our legacy was less of terrible, untested spaghetti code kind (like you, we would never write such code of course :)) and more of “legacy framework we need to replace” kind. So this is a talk about how we managed to have one team replace legacy framework (yes, including the ORM) with symfony without breaking the production system while another team was actively developing that same production system, and what process and attitude changes we feel are needed if we’re to stop legacy from creeping back into the system again.
Saturday, 2017-10-07 @ 11:45
>
Skill level:
intermediate
>
Duration: 25 min
Talk sponsored by
Vedran Križek
I have been a developer for most of my conscious life, starting when megabytes were still just puny little kilobytes and disks were way floppier than they are these days. I've used everything from 6502 assembler and Pascal to C and Delphi, but for the last 18+ years I've been a PHP developer / architect - and liked it a lot. Over those years, I've designed and developed a number of high performance custom web systems using PHP and LAMP stack, probably biggest of which is njuskalo.hr, leading Croatian classifieds averaging over 250M monthly page views.
Currently I'm working primarily as a business analyst trying to find the best way of delivering value to end users as early as possible - as a way to show our clients that iterative delivery really works, and that the entire project scope does rarely fall into the "must have" category all the time.
