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

Made with Slides.com