When tool strategy get on your nerves
Join the DZone community and get the full member experience.
Join For FreeA long time ago, before the days of code prettifiers like Jalopy, we
wrote code and we tested code. That code was fun to write. And because
it was fun to write, we were motivated to write it well and test it
well.
Welcome Jalopy
It was around 2008 when a powerful tool which auto-magically reformatted
our code was forced on us. In the beginning we rejoiced, for this tool
added "TODO: Document me!" to all methods missing Javadoc (lots). It
made it very easy to see where programmers had failed to document their
code. The numerous TODOs were also great, because they made it
impossible to find the real meaty stuff that still needed to be done.
And in classes where our constants were defined, in a specific order so
that it matched our documentation, Jalopy kindly reordered the constants
alphabetically, making it hard to match code to the documentation.
Enter Sonar
A while later, realising that programmers program bad code even though
Jalopy is present to save the world, we had Sonar forced on us. It is a
great tool, because it tells us how bad our code is and what we need to
change in order to make it good. Ahhh, what is "good" I hear you ask?
Well that is defined by a central department who knows nothing of our
projects and who doesn't care about architecture (where our real
problems lie). The people who work there only want drones who all
program in the same way, according to their rules and the rules of
academics who make a living writing books about design patterns, which
no one really understands and everyone implements wrongly in their own
way anyway. But when we realised just how "bad" our code was, it was
decided that a tool would be used to automatically modify the bad code
and make it good. Bear in mind while reading this, that the bad code
was already working well in production, yet the "good" code that was
generated still needed testing. So we started testing the generated
"good" code and came to realise it didn't always work. But never fear.
To reduce the risks, the task to change the bad code into good code was
given to human programmers. Unfortunately none had time to change bad
code into good code until the end of the release, when the real work
came to an end. Having written bad code which was bug free, some
programmers now had time to turn the bad code into good code. So they
started delivering patches to convert the code, right at the end of the
release. That scared some people, so it was decided that they could
check the good code straight into the trunk instead of doing so on the
branch using patches.
And then Sonar really ruined my day
Today, we started merging patches from the production branch into the
trunk, so that we could start on the next release. Didn't work. Merge
conflicts. Why? Because people had modified trunk and checked "good"
code in. That unforunately means that the patches which have been
tested and are known to work now need to be merged with "good" code.
The risk that we will introduce bugs during the merging is not as low as
it really should be. Some days, I really hate tools.
Still, good things come out of bad things: this was my 100th posting!
From http://blog.maxant.co.uk/pebble/2011/11/01/1320182520000.html
Opinions expressed by DZone contributors are their own.
Comments