Metrics Fun
Do you have some spare time at work? Waiting for the next user story? Or maybe just thinking what’s the meaning of that last step in test-code-refactor? Why not try to run some metrics? Maybe you have some legacy code sitting in your project, maybe is what you have just written. I can think of three metrics that quickly give you a great ROI: coverage, duplication and complexity. Of course there are many more, but let’s assume it’s the first time you run metrics on the project: you’ll be surprised with minimal effort.
Working on some Ruby code recently I tried Kwala, a metrics aggregator for Ruby. Kwala is wrapping other tools to create a nice report but it’s not easy to install. It requires dependencies to be installed manually (Saikuro and Amrita). Other than that, the tool seems to work great. Playing with Kwala I was able to find a nice piece of code with a red labeled complexity of “25”. I stripped all the actual lines and I left only the conditional workflow:
def blah()
if
case
when
case
when
when
end
when
case
when
end
when
when
when
when
case
when
end
when
case
when
end
when
case
when
end
when
rescue
when
when
when
end
else
end
if
return
else
return
end
end
The answer is no, I didn’t write the code :) But the game is simple: make that complexity disappear using refactoring. There are tons of good articles and a well written books about the topic. But here’s how:
- Search for usages of the method and try to understand how it is used and in what circumstances
- Now go inside the method and apply some embellishment like formatting and introducing meaningful new lines to split related part of the code
- Try to understand what the method is doing and write inline comments if necessary. A good technique is to connect the execution of the application to a debugger and follow line by line what’s going on
- Write unit tests that mimic usages of the method by the other parts of the application
- Write acceptances or integration tests that operates on the application interface portion which is related with that method
- Ok, with the Refactoring book and the Refactoring Workbook opened in front of you it’s time to start refactoring.
When the game is started, developing is easier and iterations are more fun. The secret is to introduce a visual feedback, something you can race against day by day to measure your improvements. It’s exactly the same satisfaction you have in front of a green bars while running the test suite and the same applies for the other metrics like coverage or removing code duplication. Final suggestions:
- Automate the most important metrics as part of the build
- Make sure nice reports from the metrics are found as part of the continuous integration report
- Make your self questions about those numbers
- Create an habit where you consistently improve the code quality as part of the micro-cycle
- Make metrics results part of the iteration showcase