Painting the picture 🖌

You’ve just started a new job, and are full of enthusiasm and ready to get stuck in…

You’re new boss approaches you and asks you to have a look at one of their old projects…

You think nothing of it, and relish the thought of looking over code that was created by a company that prides itself on high standards and strong development practices…

Then you take one look at the code…

What is this?!

What does it do?!

Why are you asking these questions? 😅

I heard an awesome quote from Sandi Metz from a talk she did at a Ruby conference:

Code is read many more times than it is written. Writing code costs something, but over time the cost of reading is often higher. Anyone who ever looks at a piece of code has to invest brain-power into figuring out what it does.

And with you joining a successful company that has spent years writing software, they have a lot of code to read.

Any company that has been around for a few years and has been successful will no doubt have a code base that they are less than happy to share with the outside world 🙈

Don’t panic!

Although you might start questioning your skills as a developer, and developing a slight case of imposter syndrome, the trick is not to panic. Most of the time developers like to show off a little bit…I know I’ve been guilty of that before. Needless to say, trying to be clever vs writing readable code is a constant battle with your own ego.

Just take a few deep breathes and:

• Skim through the list of files.
• Read the ones that stick out (and do what you think the app is supposed to do).
• Check to see if the code you have read has any tests (more than likely it doesn’t…)
• Make notes!

Why did they ask you to “have a quick look” at the code?

They want you to either change or fix something. And it something they don’t want to force on their existing developers. So they brought you in…

Probably one of the main reasons why developer churn is quite high 👀

Where to begin…

So from your notes you know where you need to add this new functionality. And you know that the area of code you need to look at is a little bit menacing. Also…it has no tests 😩

So step one…write some tests!

You want to make sure that any changes you make do not interfere with the way the application works currently. Without tests you could start changing a bunch of stuff, deploy the application, and then watch as bug reports come in as users find that the application is not behaving as expected!

This is where I would leverage a reverse TDD approach…

Reverse TDD?!

So you have a bunch of code and you don’t know what it is supposed to return. So you write a bunch of tests.

These tests are designed to fail. From the assertions you can gather useful information on what each part of the application is supposed to return. There is a brilliant talk by Sandi Metz (fanboy alert…sorry) that goes through the Gilded Rose Kata. The approach she uses has changed my mindset on how to deal with adding new features to legacy code.

When have figured out what the code should do, and all your tests are ✅, then you can start looking at adding the new feature.

Some key principles

Don’t just dive right in! You will most likely make the code look even worse. Sure, you’ll write tests to make sure your code is doing what you expect it to…but when someone else comes to add another feature to that same area of code… 😰

A quote by Kent Beck has really stuck with me during these times:

So you should start by making the existing code easier to digest. This could involve extracting code into functions that give the reader an idea of what the code is doing. The way I approach this is to build a bunch of methods that could be made into some kind of story or journey. For example:

You should be very wary when using conditionals. These are great candidates for extracting into their own methods. We can refactor this into a story-like syntax like this:

Now I know what you are thinking…It has somewhat increased the size of our class. You’ve probably heard that classes should be small and follow the Single Responsibility Principle. But I think as long as the public API of a class is limited, you should be able to create as many private methods as you need to in order to make what your public methods are doing clearer.

Probably the code you are seeing is 10x worse than this. With nested if’s as far as the eye can see. After following some of the techniques used by the Gilded Rose kata you should be on an easier path to adding additional features.

It’s not always easy

Make sure you are using source control and create spike branches to start experimenting with different approaches for the refactor. I’ve had numerous occasions where I would do a bunch of changes, then discover that it just doesn’t seem right, so I’d start again.

Once you are happy with the approach you want to take, then you can create a branch that you would be happy for someone to code review.

The crucial ingredient

Remember…always write tests! These are your safety net while you are changing existing code. You want to make sure you are delivery high quality and reliable code. I know it can seem a chore to start writing tests for areas of code that are lacking in that area, but the benefits all than make up for the time spent on it.

Conclusion

Just follow these steps and you’ll be fine.

1. Don’t be scared.
2. Take calculated steps.
3. Profit! 😜