"Working Effectively with Legacy Code" is a classic read. It dates back to 2004 but the techniques are still relevant.
+1 It’s on my list of books that every developer should read.
What's the rest of that list?
Ask HN: Good resources about legacy code?
21–30 of 41 posts
Re: Ask HN: Good resources about legacy code?
#22How did you get this job with no experience? How did you estimate the price and time to completion? Congrats and good luck
Possibly the OP has got hourly/daily rate gig.
Re: Ask HN: Good resources about legacy code?
#23> spaghetti, monolithic
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
It can be tempting to declare entire sections of legacy code - or even the entire project - to be an unmaintainable mess that isn't worth fixing. Reading code for a true understanding of how it works can be a slow, laborious, annoying process. Simply rewriting everything from scratch often appears to be easier than trying to read, understand, and fix a legacy pile of spaghetti.
Giving in to that temptation and rewriting a project instead of fixing and refactoring the existing code is almost always the wrong decision. The messy spaghetti probably started out a lot cleaner. The mess that accreted over time is often important bugfixes and design changes. Some problems only show up in the field and sometimes requirements change. The spaghetti of bugfixes, workarounds, and changes might be the most valuable part of the codebase. Throwing it out might be throwing away the accumulated knowledge and experience of many expensive developer man-years.
Instead of rewriting, preserve the bugfixes and real-world experience by refactoring the spaghetti. It can be annoying and tedious, but it's probably less work than re-debugging old problems until the "clean rewrite" accretes it's own spaghetti-like layer of bugfixes and workarounds.
Re: Ask HN: Good resources about legacy code?
#24Earlier quoted context omitted.
Since you are working with dynamic language, step 2 should include adding type annotations or whatever they are called in php. Specifying stricter types makes refactoring much easier.
Agreed. Adding type annotations is already a huge refactor in itself though and pretty risky with PHP. Once you have that done life will be much easier.
For those unfamiliar with php, or its type annotations, why is adding type annotations a risky step? Do they become enforcing?
function foo(string $bar) { ... }
foo(1234) // kaboom?Re: Ask HN: Good resources about legacy code?
#25Earlier quoted context omitted.
Agreed. Adding type annotations is already a huge refactor in itself though and pretty risky with PHP. Once you have that done life will be much easier.
For those unfamiliar with php, or its type annotations, why is adding type annotations a risky step? Do they become enforcing? function foo(string $bar) { ... } foo(1234) // kaboom?
I think your code will work because 1234 can be converted to a string. I think the trouble starts once you pass around objects.
Re: Ask HN: Good resources about legacy code?
#26Earlier quoted context omitted.
Agreed. Adding type annotations is already a huge refactor in itself though and pretty risky with PHP. Once you have that done life will be much easier.
For those unfamiliar with php, or its type annotations, why is adding type annotations a risky step? Do they become enforcing? function foo(string $bar) { ... } foo(1234) // kaboom?
Yeah pretty much. It's risky because type checking produces fatal errors that aren't always easy to trap properly. You don't realize how much a code base relies on PHPs type coercion until you add annotations and watch it blow up, in often subtle ways.
Re: Ask HN: Good resources about legacy code?
#27Earlier quoted context omitted.
For those unfamiliar with php, or its type annotations, why is adding type annotations a risky step? Do they become enforcing? function foo(string $bar) { ... } foo(1234) // kaboom?
I think your code will work because 1234 can be converted to a string. I think the trouble starts once you pass around objects.
It actually doesn't according to http://sandbox.onlinephpfunctions.com/code/8804b49c23d620228..., though different PHP versions could produce different results.
Re: Ask HN: Good resources about legacy code?
#28This mirrored my experience joining a company when my prior PHP usage was also custom code. I struggled for about a month with the current workflow of writing code, pushing it live to a hidden test area, and then getting feedback from the changes I made. Fortunately, vagrant was newish and I learned of the site https://puphpet.com/.
I set out on a mission to recreate the production environment as closely and as primitively as possible. Instead of the full 16gb legacy database for instance, I only dumped the structure and added rudimentary test data. Now my primary workflow involved local, manual testing but the feedback loop was orders of a magnitude faster than waiting for subversion changes to get deployed. Recreating the production environment 1:1 was wrought with large annoying challenges.
Barring full conversion there's various techniques that required less effort. Using scratch scripts and running the local server in phpstorm helps but stripping code down to run locally can be cumbersome. Another option I took was getting lightweight functions working in an environment like http://sandbox.onlinephpfunctions.com/ and slowly integrating them into local scratch scripts or production.
Fortunately, the future at the company involved selling Laravel as a viable option, which makes everything so much easier. I'm a big proponent of frameworks or packages over custom code or NiH as they often soften edge cases or work around quirks in the language.
Re: Ask HN: Good resources about legacy code?
#29Earlier quoted context omitted.
I think your code will work because 1234 can be converted to a string. I think the trouble starts once you pass around objects.
It actually doesn't according to http://sandbox.onlinephpfunctions.com/code/8804b49c23d620228... , though different PHP versions could produce different results.
This works with PHP 7
function foo(string $bar) { return $bar . $bar; }
echo foo(1234);
Re: Ask HN: Good resources about legacy code?
#30Earlier quoted context omitted.
For those unfamiliar with php, or its type annotations, why is adding type annotations a risky step? Do they become enforcing? function foo(string $bar) { ... } foo(1234) // kaboom?
Yeah pretty much. It's risky because type checking produces fatal errors that aren't always easy to trap properly. You don't realize how much a code base relies on PHPs type coercion until you add annotations and watch it blow up, in often subtle ways.
"Subtle" is the keyword here.