Exploratory
Refactoring:
When you are
working on a legacy codebase, sometimes you may want to understand the logic
before you actually make changes. (Michael Feathers says legacy code as
"code without unit tests". He describes lots of techniques to work
with legacy code in his book Working Effectively
with Legacy Code. There are bad unit tests also but that is a separate
issue.
Exploratory
Refactoring is an act of applying a series of refactorings to legacy codebase
just to understand what the code does. During this exercise you'll check-out
some of the code files but you'll not commit it. Once you understand the
internal logic you'll throwaway all of the changes you made by roll-backing all
the check-outs. Once you got the big picture of what changes you need to do and
where to do etc. then you'll start actual refactoring and make code changes.
The kind of
exploratory refactorings are like Extract
Method, Decomposing Conditionals, Rename Method, Rename Variable, Introduce
Explaining Variable etc. Some
times its just code formatting like indentation,
adjusting the number of blank lines and grouping the code fragments. During
this you just want to make the parts of the code as apparent as possible.
During this
phase you'll also get an idea of how clean and smelly the codebase is and how
complex or easy the logic is, what is the intrinsic structure of the code, reveal
the intensions of the author, which classes and functions hold what functional
area of the application, and even get an glimpse of the environment like the
coding and naming styles and standards followed. Overall you'll know the
quality of codebase also.
You really don't
have to be very careful in applying the refactorings because it is throwaway
changes. The closer you get to real-life refactoring, the more you can learn
from it. You will get to see some unexpected inter-dependencies, which can
influence your real refactoring later on.
Keep
refactoring! And develop with pleasure!
