 |
|
 |
 |
||
|
 
Felipe Gaucho's BlogCode fitness: how fat is your code? how tall?Posted by felipegaucho on January 25, 2007 at 02:26 PM | Comments (1)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:
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:
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. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first)
| ||
 java.net RSS Feeds
|
