Category Archives: refactoring

Newsflash: The Wrong Abstraction

I’ve just read an interesting article of Sandi Metz. I consider it important (and provocative) enough to dedicate a newsflash to Sandi’s article. Basically, my article is a commented link. Mind you, how often did you do stupid things during your working hours just because you valued existing to code high?

That’s a common trap I’ve often watch catching other people (and myself, of course). Like Sandi says,

Existing code exerts a powerful influence. Its very presence argues that it is both correct and necessary.

Existing code tricks you into believing it’s good code

Every once in a while you come across complicated code, and you say by yourself, “whow! Such a sophisticated code! It has to be the essence of wisdom of generations of programmers!” More often than not, it’s just clumsy code generations of programmers contributed to without knowing what they did. It’s really hard to detect such a situation. Because you sometimes the code is complicated because it has to be. You never know.

Don’t be overly respectful!

However, sometimes it’s good not to be afraid of redundant code. Adding the wrong abstraction is worse than suffering from a few duplicated lines of code. Often my team tried to unify objects that are identical in the eye of the stakeholder. Consider the simple example of a mailing address. It’s simple, it’s even standardized by your postal office (and probably the ISO and DIN committees, but I didn’t check). Thing is, when we tried to implement the unified address in my previous company, we started to hear “yes, it’s identical, except for…”.

That’s a surprisingly common example. Trying to merge concepts that are identical – only differing by a small margin – may be the first step to unhappiness.

You can refactor in two directions: back and forth

I’d rather you developed an instinct when to introduce abstractions, and – more important – when to unravel abstractions that already have been introduced in your code base. Refactoring isn’t a one-way road. Most of the time you go forward, but there’s a good reason why you can apply refactoring also the other way round. In fact, the notion of “forward” and “backward” is misleading. We’ve been taught to believe that reducing code duplication is good, which is why we instinctively attribute a direction to refactorings, but that’s s subjective attribution which may be right in most situations and wrong in others.

That said, I recommend you to read Sandi’s article. It’s a fast-paced read that’s clearly worth you attention.

The JSF Code That’s Just a Bit Too Clever

One of the best ways to improve your programming skills is to read code written by others. Today I was puzzled by a program that did work – but I couldn’t find out why. As I found out, it’s a fairly clever piece of code, and I guess you can learn a lot by reading it. It demonstrates the importance of the separation of concerns principle, and it demonstrates why boredom is a virtue amongst programmers.
Continue reading

The Art of Refactoring: Removing Code Duplications

Refactoring code means to transform it by rules that can be automated. In most cases the goal is to simplify the code. Sometimes it is not easy to achieve this goal because the automated rules are not flexible enough to recognize code duplications that human beings see at first glance. This articles shows some hints of mine to solve this problem.

Continue reading

There is no accurate documentation of your code but your code itself

It’s a common misconception that every program needs documentation. Most people seem to be terribly scared by programs lacking documentation. Whenever I am asked where my documentation is, inevitably this question is followed by the next question: “What happens if you leave the company? Nobody┬┤ll be able to figure out your code!”

That’s nonsense.
Continue reading