Depending upon the subject, some of us are lucky to finish a functioning project so the thought of improving code after the fact – especially if there’s a new project due soon – is a distant one. However, they may be tricked into refactoring their code if asked when you say the magic words: “Refactoring is not rewriting code”. The definition, as defined by its creator is:
“a change [or changes] made to the
internal structure of software to make it easier to understand and cheaper to
modify without changing observable behavior.”
In
reality, the process may involve:
- new
code, but it must not change the behavior of the original code; - ensuring
the system works before and after each refactor, including original unit tests; - creating
unit tests to verify our refactoring has not changed system behavior; - changes
that individually are minute, but combined lead to a healthier program; - eliminating
duplicate code, potentially changing variable names, and more.
It is not
simply cleaning up code, but rather reorganizing it in order to make it easier
to trace and understand, as well as add functionality to in the future.
For our purposes, this may be a very
important concept to learn but it may be some time before we get to implement
it, unless we’re coding or maintaining an entire program for our capstone; however,
it is important to understand when to do so. According to my sources, the best
time to do so is before you add new features to an existing program, or right
after you’ve already shipped it. For the former, it makes these new features much
easier to add when the program is much more readable and makes the program better
for having made the changes. As for the latter, it makes a lot of sense to
snoop around for ways to reorganize code after you’ve spent so much time on it,
and in a mad dash to finish it towards the end no doubt. Years’ worth of work
is no doubt going to have some inconsistencies that fell through the cracks in
the course of development.
As for implementing these changes, there are several methods, including Red-Green-Refactor, Abstraction, Simplifying Methods, as well as many others we won’t cover. In R-G-R, red means stop and determine what to develop – usually with a new test that fails, getting this new development to pass tests (green), and finally refactoring to optimize. Abstraction is used to address duplicate code and can be done by restructuring hierarchies using the Pull-Up [pulling up code into a superclass to be shared more effectively] or Push-Down [pushing down code to more subclasses from a superclass] method. Finally, Simplifying Methods is an effort to simplify older code by consolidation and reducing interclass complexity. Hopefully this helps develop an understand of refactoring, in fact, I had to do quite a lot of refactoring to this blog to get it down to size!
Sources:
Refactoring – Martin Fowler
Refactoring – Agile Alliance
Code Refactoring Best Practices: When (and When Not) to Do It
From the blog CS@Worcester – Press Here for Worms by wurmpress and used with permission of the author. All other rights reserved by the author.