I don’t think the vertical axis should be “Probability of being targeted by a refactoring effort”. I think it should be “Amount of refactoring required”. There is always refactoring to be done, it’s just a lot less. Where I work, the probability of a piece of code to be refactored is close to 100%, no matter how clever (or not) it is.
Interesting. I agree that it is missing some timescale (e.g. probability of being refactored in the next 6 months, or probability of being refactored in the next refactoring initiative.)
However, if we use Wikipedia’s definition:
Code refactoring is the process of changing a computer program’s source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software.
then I would argue that some code should be exempt from refactoring; refactoring has got to pay for itself from the nonfunctional attributes alone. Surely some of the code is good enough that such an effort wouldn’t be justified even if the new code was perfect?
(If you mean any of the code has a high chance of being subject to *change*, rather than *refactoring*, then I agree with you.)
A refactoring effort should have a particularly high justification hurdle because of the propensity of programmers to want to polish forever.
(This is a case of “Julian doth protest too much”, because my current refactoring effort was somewhat borderline in value. I actually decided to roll it back at one point, before changing my mind and proceeding. Despite that the code is much smaller, cleaner and simpler and despite that it’s passing all unit tests now, I’m suspicious that my life is about to become difficult when it gets deployed.)
Articles
Comment by configurator on July 1, 2010
I don’t think the vertical axis should be “Probability of being targeted by a refactoring effort”. I think it should be “Amount of refactoring required”. There is always refactoring to be done, it’s just a lot less. Where I work, the probability of a piece of code to be refactored is close to 100%, no matter how clever (or not) it is.
Comment by Julian on July 1, 2010
Interesting. I agree that it is missing some timescale (e.g. probability of being refactored in the next 6 months, or probability of being refactored in the next refactoring initiative.)
However, if we use Wikipedia’s definition:
then I would argue that some code should be exempt from refactoring; refactoring has got to pay for itself from the nonfunctional attributes alone. Surely some of the code is good enough that such an effort wouldn’t be justified even if the new code was perfect?
(If you mean any of the code has a high chance of being subject to *change*, rather than *refactoring*, then I agree with you.)
A refactoring effort should have a particularly high justification hurdle because of the propensity of programmers to want to polish forever.
(This is a case of “Julian doth protest too much”, because my current refactoring effort was somewhat borderline in value. I actually decided to roll it back at one point, before changing my mind and proceeding. Despite that the code is much smaller, cleaner and simpler and despite that it’s passing all unit tests now, I’m suspicious that my life is about to become difficult when it gets deployed.)