REFACTORING FOR EVOLUTION

Refactoring For Evolution

Abstract

The implication is that the traditional approach of creating a (nearly) complete set of logical and physical data models up front isn't going to work.  The main advantage of the traditional approach is that it makes the job of the database administrator (DBA) much easier - the data schema is put into place early and that's what people use.  However there are several disadvantages.  First, it requires the designers to get it right early, forcing you to identify most requirements even earlier in the project, and therefore forcing your project team into taking a serial approach to development.  Second, it doesn't support change easily.  As your project progresses your project stakeholders understanding of what they need will evolve, motivating them to evolve their requirements.  The business environment will also change during your project, once again motivating your stakeholders to evolve their requirements.  In short the traditional way of working simply doesn't work well in an agile environment. 

Introduction to Refactoring

Refactoring

Martin Fowler (1999) describes a programming technique called refactoring, a disciplined way to restructure code.  The basic idea is that you make small changes to your code to improve your design, making it easier to understand and to modify.  Refactoring enables you to evolve your code slowly over time, to take an iterative and incremental approach to programming.  Martin's refactoring site, www.refactoring.com, is a good online resource.

What is refactoring?

Refactoring is the process of changing small parts of your application to improve the application or code without changing it's behaviour. Wikipedia defines refactoring as follows: (Hill, 2006-12-31)

Code refactoring is the process of changing a computer program's internal structure without modifying its external behavior or existing functionality. This is usually done to improve code readability, simplify code structure, change code to adhere to a given programming paradigm, improve maintainability, or improve extensibility.

A critical aspect of a refactoring is that it retains the behavioral semantics of your code, at least from a black box point of view.  For example there is a very simple refactoring called Rename Method, perhaps from getPersons() to getPeople().  Although this change looks easy on the surface you need to do more than just make this single change, you must also change every single invocation of this operation throughout all of your application code to invoke the new name.   Once you've made these changes then you can say you've truly refactored your code because it still works again as before.

It is important to understand that you do not add functionality when you are refactoring.  When you refactor you improve existing code, when you add functionality you are adding new code.  Yes, you may need to refactor your existing code before you can add new functionality.  Yes, you may discover later on that you need to refactor the new code that you just added.  The point to be made is that refactoring and adding new functionality are two different but complementary tasks. (Hill, 2006-12-31)

 

Problems with Refactoring

In the February 2002 issue of Software Development I described ...