Home

Easy Change

for each desired change, make the change easy (warning: this may be hard), then make the easy change

— Kent Beck, September 25, 2012

Here’s some code from our main application helper. It provides a small method for redirecting the user based on a goto parameter. It uses two helpers itself to append google analytics parameters to the url before redirecting.

Originally, it was uncommented. I’ve added a few here to highlight what goes through my head when first reading it.

So the methods are somewhat smelly, but not enough to warrant refactoring when you don’t need to make a change in this area.

Fortunately, Business has decided that they would like to append the BuyId parameter to the redirect url in much the same was the analytics parameters are currently.

Our first instinct might be to just add the param inside the append_ga_params method. This would be incorrect; since BuyId is not a google analytics parameter, the name of the method would be misleading.

Alternatively, we could just plop the param onto the end of the url directly in redirect_to_latest_or_goto. Adding some string building into that method might be considered mixing layers of abstraction. It also does nothing to explain what we’re doing the way append_ga_params does.

Make the Change Easy

It’d be really nice if we had a generic append_params helper available to add our BuyId. This is basically what append_ga_params is doing, except that it’s over specified.

Let’s tease that logic out into a separate method and call it from our original. At the same time we can clean up some of the smells we noticed earlier.

Notice that we keep the original methods’ interfaces exactly as they were. This should allow any existing tests to pass without modification and give us confidence that we’ve gotten it right.

In my case, append_ga_params was not marked private. If it were I’d probably do all this a bit differently. For now, we decide to play it safe and leave the class interface alone.

With tests passing, we commit our code and shift gears from Refactor to Feature.

Make the Easy Change

Conclusion

This was definitely a simple example, but it’s nice to see how this two-step process works on something realistic. It’s not difficult to extrapolate this up to something larger.

28 Nov 2012, tagged with ruby