Amusement Park Methods

Sometimes you stumble upon amusement park methods.

Remember the feeling when first going through the gates of a big amusement park? When you get a first glimpse of how vast it is? you see some rides close by and at the distance you see the tall roller coasters. That's the feeling I'm talking about.

You start scrolling through the method. Just to understand what's before you, you want to see how long it gets. You scroll and scroll and it goes on and on, and you start to go faster but it never ends. As Louis and Clark tried to find a path through the Rockies to get to the Pacific, you are making your way through this monstrous method, this fantastic creation.

As you progress you discover gems, places you would like to have the time to appreciate. You see static methods, more and more of them, this one reaching the database, this one getting some configuration data, that one directly contacts some external interface.

After clearing some dense string manipulation statements you see a variable that looks familiar. It is called "Type". You decide to go back and indeed it is referred throughout the method. You immediately think of polymorphism.

You continue. Something new appears at the bottom of the screen but you're still not sure. Could it be? You scroll down some more and it is revealed in its full magnificence. A colossal If-Else statement, something that shadows everything you ever knew. It goes on and one. Endless identations with complex conditions. It must be the creation of generations upon generations of developers. Like stalactites, this is a magical creation of nature. 

You need to make a small change. You find the exact place. What will you do? Will you just make it and run the entire flow? That might work.

It might work but it wouldn't do.

You are a professional.

Would you miss all those great rides?

You decide to tame the beast. It is just you and the machine.

You want to handle it all together but you know it is too risky. The stakes are high. At any moment someone might come up with something more urgent to do and you will get stuck with nothing.

So you extract a small part of the method, the area where you need to make the change, to a different method. Sometimes it will be to a different class. You replace all the static calls with objects that will make the static calls in production but in the test will return whatever it is you tell them to.

You write one test to run the new method. To make it pass you compose the fake data. It passes. Once you have the basic infrastructure more and more tests are flowing through your fingers. You cleared the area for work. You have the method under a harness.

Now you write the tests for the change you need to do and indeed it fails.

You make the required change and the test passes.

Feeling satisfied you look at all the good the method has yet to offer. You wink at it with a promise for another visit. You mount your horse, tip your hat and ride into the horizon.