Code Refurbishment
Join the DZone community and get the full member experience.
Join For FreeWithin our industry we use a huge range of terminology. Unfortunately
we don’t all agree on what individual terms actually mean. I so often
hear people misuse the term “Refactoring”
which has come to make the business in many organisations recoil in
fear. The reason for this fear I’ve observed is because of what people
often mean when misusing this term.
I feel we are holding back our industry by not being disciplined in our
use of terminology. If one chemist said to another chemist “we are
about to perform titration”,
both would have a good idea what is involved. I believe computing is
still a very immature science. As our subject matures hopefully we will
become more precise and disciplined in our use of terminology and thus
make our communication more accurate and effective.
Refactoring is a very useful technique for improving code quality and
clarity. To be precise it is a behaviour preserving change that
improves a code base for future maintenance and understanding. A good
example would be extracting a method to remove code duplication and
applying this method at every site of the duplication, thus removing the
duplication. Refactoring was first discussed in the early 1990s and
became mainstream after Martin Fowler’s excellent “Refactoring” book in 1999.
Refactoring involves making a number of small internal changes to the
code structure. These changes will typically not have any external
impact. Well written unit tests that just assert externally observable
behaviour will not change when code is refactored. If the external
behaviour of code is changing when the structure is being changed then
this is not refactoring.
Now, why do our business folk recoil in fear when this simple and useful
technique of “refactoring” is mentioned? I believe this is because
developers are actually talking about a much more extensive structural
redevelopment technique that does not have a common term. These
structural changes are often not a complete ground-up rewrite because
much of the existing code will be reused. The reason the business folk
have come to recoil is that they fear we are about to head off into
uncharted waters with no idea of how long things will take and if any
value will come out of the exercise.
This example of significant structural change reminds me of when a bar
or restaurant gets taken over by new management. The new management
often undertake a refurbishment exercise to make the place more
appealing and suitable for the customers they are targeting. A lot of
the building will be preserved and reused thus greatly reducing the
costs of a complete rebuild. In my experience when developers use the
term “refactoring” what they really mean is that some module, or bounded context,
in a code base is about to undergo significant refurbishment. If we
define this term, and agree the goal and value to the business, we may
be able to better plan and manage our projects.
These code refurbishment exercises should have clear goals defined at
the outset and all change must be tested against these goals. For
example, we may have discovered that code is not a true reflection of
the business domain after new insights. These insights may have been
gleaned over a period of time and the code has grown out of step to
become an approximation of what the business requires. While performing
Domain Driven Design
the penny may drop with the essence of the business model becoming
clear. After this clarity of understanding the code may need a major
overhaul to align it with this new understanding of the business. Code
can also drift from being a distilled model of the business domain if
quick hacks are put in place to meet a deadline. Over time these hacks
can build on each other until the model no longer describes the
business, it just about makes itself useful by side effect. During this
exercise our tests are likely to see significant change as we tighten
up the specification for our new improved understanding of the business
domain.
A code refurbishment is worthwhile to correct the core domain if it's
about to undergo significant further development, or if a module is
business critical and needs to be occasionally corrected under
production pressure to preserve revenue generation.
I’m interested to know if other folk have observed similar developments
and if you think refinement of this concept would be valuable?
From http://mechanical-sympathy.blogspot.com/2011/08/code-refurbishment.html
Opinions expressed by DZone contributors are their own.
Comments