Refactoring is the process of changing or improving the internals of source code while preserving its behavior. Refactoring is done to make code more expressive, clearer, less complex and more maintainable. The waterflow approach to developing software with big up-front design[1] is hard in the time of rapid changes, so refactoring plays vital role for keeping the code in shape. It allows our design to evolve as requirements change and to make more simple code without bothering for predictions about future features which very often will not be needed. By improving the source code, we make it less error-prone. Refactoring in fact speeds up the developing process instead of slowing it down, despite the additional effort to change the code, since it improves the design of software, makes it easier to understand and cheaper to maintain in future. Having good design allows rapid development, without it the development speed can suffer a lot. A design which looks perfect at the beggining could become poor, as requirements change and source code evolutes. Poor design will sooner or later slow you down [2]. Refactoring can be applied in lots of development processes like PIL, RUP, Extreme programming, Scrum and so on.
We refactor most often when we notice the so called “code smells”[3]. A “code smell” is a piece of code which works but still doesn’t look good. The most important “code smell” is duplicated code. Other “code smells” are large class, long method, long parameter list, conditional complexity, inappropriate intimacy, feature envy, data class and so on.
When we refactor it is very important to have automatic support from the development studio, it makes the refactoring process easier, less error prone, faster and gives the developer more courage. Our Java SAP Netweaver IDE is built on top of the Eclipse platform which offers a lot of options for refactoring which make our lives easier. It allows automating some very short refactoring steps, although many bigger refactorings involve a series of such steps.
So when should we refactor? If there is a good coverage of the code with unit tests we can be more aggressive about refactoring and refactor with more confidence. In most cases if a problem occurs after a refactoring step the unit tests will fail and we will fix the bug. Having these preconditions we can refactor throughout the entire project life cycle. In fact one of the “Extreme programming” practices is called refactor mercilessly [4]. Another point is called the “refactoring hat”[5], the meaning is that the development process should be split in distinct periods of refactoring and adding new features although these periods can be even 15 minutes long. On the other hand for simpler refactorings like renaming a parameter it may be not worth waiting for the next refactoring step. Imagine you have to add new functionality or fix a bug but it is hard due to the current source code, refactoring can help making the code simpler, clean and readable.
What happens if our application doesn’t have good test suite or if the test suite is hard to be run often (you have a bunch of server tests and to run them you need to restart the server which takes several minutes). In this case we are less confident about our changes, although some simple refactorings like renaming a parameter or extracting a function are performed by the IDE. Being less confident we should refactor rarely but for a longer period. Instead of several short refactoring periods, we will have less, longer refactoring steps.
Refactoring also is an integral part of “Test driven development”, which lifecycle can metaphorically be explained with the slogan “red green refactor”. This comes from the fact that first you write a test which doesn’t pass (junit’s red bar), then write code to pass the test (green bar) and finally refactor to remove duplication and other code smells. I will dedicate some of my future blogs on “Test driven development”.
Refactoring is a series of small steps which preserve current code functionality. It helps keep the design and source code clean and maintainable. Given an good suite of automated tests gives courage to perform refactoring more often and thus have better code. This helps you find bugs, understand the code better and finally to program faster.
