Refactoring:Improving the Design of Existing Code

Watch for warning signs in your own code –- that is "code smells" !!!

The Lunch 'N Learn session really did not start with that line, but that is the most important guideline in refactoring.


Every Lunch 'N Learn Sessions is something to look forward to hmmmm free lunch? Well you may think it is but there is something more to it, lots of ideas were shared during these small talks from the Exist Gurus and this time it's one of Exist best, Ms. Deng.


What is Refactoring? Ms. Deng, gives quite an opening through asking a question.
Everybody seems dumbstruck, well maybe because it's the first time that the participants are being asked early in the discussion even before they can do so or they are just quiet familiar with the word or they're full of ideas? I bet they have been refactoring all there programming life, everybody does right?


What really is Refactoring?
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Its heart is a series of small behavior preserving transformations. Each transformation (called a 'refactoring') does little, but a sequence of transformations can produce a significant restructuring.

Why should you refactor?
– Refactoring improves the design of software
– Refactoring makes software easier to understand
– Refactoring helps you find bugs
– Refactoring helps you program faster

But when should you refactor?
– Refactor when you add a function
– Refactor when you need to fix a bug
– Refactor when you do a code review

In short refactor when your system changes otherwise its pointless, refactoring a changing software so it can be easily changed in the future gives you a payback.
Take note when you refactor you should also test, testing is very important underpinning to refactoring, as Fowler says:
“Think of it as walking a tightrope without a net. If you are good at walking a tightrope, and it's not that high up, then you might try it. But if you've never walked a tightrope before, and it's over Niagara Falls, you probably want a good net.”

Code smells or code that smells bad.

• Duplicated Code
• Long Method
• Large Class
• Long Parameter List
• Divergent Change
• Shotgun Surgery
• Feature Envy
• Data Clumps
• Primitive Obsession
• Switch Statements
• Parallel Inheritance Hierarchies
• Lazy Class
• Speculative Generality
• Temporary Field
• Message Chains
• Middle Man
• Inappropriate Intimacy
• Alternative Classes with Different Interfaces
• Incomplete Library Class
• Data Class
• Refused Bequest
• Comments

Listed above are just the 22 code smells, but there are 73 code smell refactorings in 7 categories.

Lazy Class

A class that isn't doing enough to pay for itself should be eliminated. A class isn't doing very much.

Move all its features into another class and delete it. Useless components are subjected to Inline Class.

Extract Hierarchy

You have a class that is doing too much work, at least in part through many conditional statements.

Create a hierarchy of classes in which each subclass represents a special case.

For more on refactoring read:
Refactoring:Improving the Design of Existing Code by Martin Fowler


“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”