How To Live With Legacy Code
What is "legacy code"?
Legacy code
might be...
grafted together from lots of
different things
heavy, inflexible, and monolithic
features hastily layered one on top of another
probably in need of a total rewrite
As a junior developer,
legacy code will most
likely be your reality.
(If you're lucky,
no one will try to poison
you in your first week.)
Best practices you learned at MA may not be standard business practice.
TDD?
"We prefer...
visual acceptance testing."
Refactoring?
"Refactor? But... it works?"
Code reviews? Pairing? Retrospectives?
"WHERE ARE MY FEATURES?!"
Where to begin?
Tip #1
Pen and paper!
Make diagrams to learn and understand your domain.
(yes, I know "there's a gem for this". I don't care. You learn more this way.)
Fig. 1: Enterprise standard Rails production database
Find the parts of your system that...
are too tightly coupled...
have external dependencies...
are not what they seem...
You may be tempted to spend the rest of your afternoon fixing these problems.
What do we say to the
God of Refactoring?
Not today.
Don't submit
huge fixes.
Because...
(about the product requirements)
Tip #2
Read the tests
Jk lol. There won't be any tests.
If there are, they'll probably be broken and badly-written.
In PHP.
BUT
A great way to learn
Write your own tests!
Start from the bottom.
Pick the simplest-looking model, controller, whatever
Give every method
its own test
It's not TDD
But it's better than nothing.
One thing that any codebase can always benefit from...
Good documentation.
Tests happen to be executable documentation.
Even a small
amount of tests
Produces more
certainty than what
you had before.
Make do with
what you have.
Nobody will rewrite their codebase at the behest of a junior dev.
(translation: "All legacy code must die.")
But first, it must serve.
And when the time is right, you can kill it with fire.
fin
