Shahzad Bhatti

February 14, 2006

Refactoring

Filed under: Computing — admin @ 7:38 am

Refactoring
Since Fowler’s Refactoring book and adaption of the this term
in the agile community, everyone is board on refactoring. It’s a great
tool to prevent stale code. An ability to adapt to change is a survival
for any business and you continuously need to align your software to make
sure it can change with speed of the business.

Strictly speaking, refactoring is modifying a code without changing external
behavior. Often at the end of release cycles, developers apply quick
hacks to finish the deliverables. Most agile environment dedicate a
few days after each release to clean up the code. Many also use a geek
week after a couple of iterations to do this refactoring or make
structural changes to the aplication.

The point of my rant is two fold refactoring: types of refactoring and when
to use refactoring.

A software needs to continuously adapt and
modify as business requirements change, however I find people use the
term refactoring too loosely. I consider refactoring a minor change in
the code without breaking the contract, however every day I hear people
use the term “refactoring” when they mean redesign, rearchitect or completely
rewrite the software or a piece of software. I acknowledge it’s very cool
word, but I find it nauseating when it’s used improperly. I have seen a
number of projects that start from modest size with a couple of average
developers to large size. In many cases the code is not properly maintained
(or refactored) until it simply fails to meet customers’ expectation. So,
they will start to addressing the design or architecture issues that
are at the heart of proplem and start making major changes in the software.
Such effort of major redesign or rearchitecture cannot be labeled
refactoring or may be it should be labeld as design refactoring as opposed
to code refactoring.
Ideally, development staff need to allocate a few days or a week
quarterly to address the design and architecture issues and adapt its
design with emerging needs of the customers. You can call it a geek week
and spending a week quarlterly will be a lot effective than rewriting the
software.

On the second part, when to use refactoring I find that most agile
methodologies encourage speedy delivery of the software and
often this gives the impression to move ahead with minimal design or
architecture and refactor a we proceed. Though, I find that architecture
needs to be continuously evolve based on needs, however to start with
no architecture or very minimal one is recipe for rework and waste of time.
Such redesign (or as some people call “refactoring”) is not free, for example
it may require changing the interfaces, switching from RPC based
architecture to messaging based. For a sizeable project, it make sense to
spend a few weeks to nail down immediate and emerging needs of
the application so that even if the software is not able to handle
future needs, it is able to do so in future. One thing that can make a
big difference is having an experienced architect who has build similar
systems before and understands the business domain of the application.
The idea of initial architecture is to have capability to handle future
requirements even when those features are not implemented.

No Comments

No comments yet.

RSS feed for comments on this post. TrackBack URL

Sorry, the comment form is closed at this time.

Powered by WordPress