Stefan said:
This leads directly to software metrics. Here you can define much better
what you are doing, instead of saying "I am refactoring",
I hope not! Many refactorings are simple 1 minute tasks. The power
comes from doing many of them, but the idea is do each as the developer(s)
see them. They write something, it works, they can clean it up by refactoring
right there, before they check it in, but running the units tests as they go
along. Do you really think that productivity is improved by first
measuring the last hours of code, compare it to last nights code, refactor,
then measure again? No, of course not.
I CAN see the place for metrics but it isn't one to one with refactoring
efforts, because many refactoring tasks are just too small to measure. Metrics
could be used to identify and quantify 'smelly' parts of the code (as certain
folks like to call less than great code). This might
generate a "story" (part of the backlog) which can become a task that a
developer can work on for a day or two. Metrics before and after such a
multi-day task would be very useful. Metrics before/after any refactoring would
be rediculous, but code metrics as part of nightly builds would help to
illustrate any emerging trends.
A nightly build set of metrics could be used in combination with other project
metrics.
Sort of good we really got a lot of the tasks for the next release complete,
bad the complexity metrics shot up during the efforts.
Implication: put a little more effort into refactoring the complexity during the
next iteration.
By using software
metrics you can say your software is better
Yes, but, asking another programmer if the class is understandable, or
explaining the code, can show them where the code is not as organized as it
could be. Many times engineers can see disorganization as soon as they have to
talk about code with each other, so they don't need to have tools to help them
determine where it stinks.
One thing for everyone to keep in mind is that many refactorings aren't A is
better than B, they are make "A into B", but there is also a cooresponding
possibility to make "B into A".
As the article by Joel Spolsky referenced by Karl v. Laudermann said
"All I would do is logical transformations -- the kinds of things that are
almost mechanical and which you can convince yourself immediately will not
change the behavior of the code."
and "And in fact I never really had to think very hard, and I never had to
design a thing, because all I was doing was simple, logical transformations."
--
http://www.joelonsoftware.com/articles/fog0000000348.html
But also note that before and after Joel great 3 week effort some metrics would
have been great.
In summary: when measuring the results of lots of refactoring, metrics are
useful, but they don't have much of a role when speaking about everyday refactoring.
-Paul