What is refactoring?

Refactoring is a process of turning badly architected code into well architected code. Generally you will find that as you refactor your code will exhibit more design patterns.

Where did all these ideas come from?

The concept of Refactoring started in Smalltalk with many of the famous OO people including Johnson of the Gang of Four. And in fact Gamma wrote the forward to the Refactoring book. Martin Fowler actually wrote the book on refactoring by that name which is a good resource for information about it. Refactoring is also a tenet of Extreme Programming, but I think it is important even if you don't otherwise follow the Extreme Programming way.

How does this change design using design patterns?

If it is easy to refactor code to improve its design and you can do so without risk of breaking code then it drastically changes your coding philosophy. It means you can do less design up front and allow your code to inform you of architecture that is needed. Starting with a good design is still a good idea.

What does this mean for optimization of well design programs?

Refactoring means you can reorganize code to create a good design and also to optimize only the sections of code which actually need it. Also, if some code has been optimized so that it is no longer flexible then it can be refactored as needed to make it flexible. Remember that you as a programmer never really have a good idea what is slowing your program down. Always use a profiler to find out. A profiler is a tool which actually executes your code and determines what percentage of its time is being spent in different methods. There is a rule of thumb known as the 90-10 rule. It says that your program spends 90% of its time in 10% of its code. This means that it is useless to optimize anything that isn't that 10% of the code. And not matter how inefficient the other 90% is you won't notice it.

How to pull it off without breaking everything?

It is difficult to rapidly change code and be sure you haven't introduced bugs. That is why it is necessary to do unit testing. Unit testing means testing small sections of code like a class to be sure they do what they are supposed to. In good object oriented systems having each object do what its supposed to leads to an entire program that works. You also don't need to test simple things like accessors, instead focus on boundary conditions. Use a testing package and run your tests constantly. Its important to never go more than one refactoring without having compiling working code. Another thing that will eventually help you do refactoring is that tools are beginning to be made which can do specific refactorings for you.

When to do it?

You should constantly alternate refactoring with coding. While coding you should only add code which means you should never break a test case on the other code. Make sure to add tests as you write new code. While refactoring you should not add new functionality only reorganize code and fix tests to match the way it should now work. Its a good idea to know which one you are doing at any given time. Alternate doing them in half our to hour blocks or whatever works for you at the time. Another way to know when to refactor is what some call Bad smells in code. This is a list of some of the bad smells you may encounter.

• Duplicate Code - use the rule of three, the third time you duplicate code you need to refactor
• Long Method - most methods don't need to be more than 3 lines long in my opinion
• Long Parameter List - most of what a method needs should be in its object, or it should know who to ask to get it. Thus you don't need long parameter lists
• Divergent Change - if you have an object that would need to be frequently changed for independent reasons this is often an indication that it should be two objects
• Shotgun Surgery - sort of the opposite of Divergent change. This is when you make a change and it requires changing lots of little things throughout the code. It often means you need a object to represent all those things
• Feature Envy - often occurs when a method is on the wrong class, so it has to call half a dozen accessors on some other object just to calculate something.
• Data Clumps - if you see many objects having the same set of fields this is often an indication that those things should be an object
• Primitive Obsession - if primitives are used for things that should be object i.e. double for a currency amount
• Switch Statements - use polymorphism or visitor instead
• Lazy Class - don't be afraid to remove a class that is no longer doing anything
• Speculative Generality - occurs when code has all sorts of hooks and special cases to handle possible cases that aren't needed now
• Temporary Field - a field of a class that is only used some of the time
• Inappropriate Intimacy - too much coupling between classes
• Data Class - objects which just hold data and don't do anything
• Comments - this needs explaining. Comments are good, but clear code is better. Use comments to say when you aren't sure about something and to explain why you do something

jwalker@cs.oberlin.edu