We refactor most often when we notice the so called “code smells”. 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 . Another point is called the “refactoring hat”, 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.
 [Wikipedia] Big Design Up Front
 [Fowler] Is Design Dead?
 [C2 Wiki] Code Smells
 [extremeprogramming.org] Refactor Mercilessly
 [C2 Wiki] Refactoring Hat
 Refactoring Portal