Code fitness: how fat is your code? how tall?
I recently attended a
JUGS meeting where Prof. Nierstrasz introduced some
details about his new book, titled Object-Oriented
Reengineering Patterns. Very interesting lecture based on a project that aims to research and to produce
tools for supporting the refactory of legacy code. Professor started asking the attendants
what you mean by legacy code? and also presented some basic concepts about patterns and software
reengineering. Then he introduced MOOSE
- an environment for reengineering that comes with a tool that produces several views about the
complexity of classes in OO projects. One of these views was very impressive for me, the one that show
a class diagram based on code metrics like number of attributes, number of methods
and line codes as code width, code height and code color - I immediately started
to associate that with human caracteristics. Ok, the professor didn't suggested nothing about biometrics applyied to
software, even because it shouldn't make sense to apply such concept to an inanimate stuff, but it was
a funny mind game for me, to think about the code fitness. The two images
below gives you a glimpsy about that:
Figure 1 -
A Class Diagram.
A Class Diagram gives you a nice view about the hierarchical relationship between the classes, but
does not represent too much about the quality of the code on each class. If one is required to choose a class
on the above diagram for starting a code refactor, which class should be? Now, check the same class diagram
presented through a MOOSE view:
Figure 1 -
A Class Diagram with physical attributes.
At first sight, it is not so easy to understand what class is better or worst, but in a few seconds you
start to figure out that more complex classes produced darker and bigger boxes. On the figure, the dark
boxes represent classes with more lines of code and the tall boxes represent classes with more methods.
And, of course, you can
imagine several possibilities of representation with different shapes, colors or even including figures
to represent different software quality deviations.
The physical attributes of the classes give us a very nice feeling about the bug champions candidates :)
Imagine what is the shape of your current project. What is the shape of the classes? Lean classes?
Imagine the silhouette of that weird code you noticed last year, and what about all that minor problems
your team didn't had time to fix on the past?
I know there is several other tools and projects out there, but for me it was the first time I thinked about
code with physical attributes. So, I decided to share this experience and suggest you to visit the
project of the Bern University and try the MOOSE tool.
* MOOSE is written in Smalltalk, but it has also an Eclipse plugin that allow us to export java
and jsp source code to a format understood by the Moose. More: there is a company that produced
a compiler of Smalltalk code to Java, but I don't
know if it is still available.