Refactoring to Patterns: About Refactoring

I am reading this pretty old (2004) book by Joshua Kirievsky called Refactoring to Patterns, which I would like to study deeper and share what I learn with others.

The book, as suggested by its title, combines two key concepts in software development: Refactoring and Design Patterns. In fact, the book argues that great software designs are better understood and learnt not as stand-alone masterpieces of software craftsmanship, but by studying how they emerge through refactoring.

What is Refactoring?

Refactoring is behavior-preserving transformation, "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior." [Martin Fowler]

Refactoring involves

• removing duplication, 
• simplifying complex logic, 
• and clarifying unclear code.

To refactor safely and with courage, you need a set of automated tests that you can run quickly to confirm that your code still works.

Refactoring should be done in small steps that take seconds or minutes.

It's better to refactor continuously, rather than in phases. If you see code that needs improvement, improve it. If you need to implement an important feature by tomorrow, first finish the feature and refactor later. Refactoring must co-exist harmoniously with business priorities.

Refactoring Motivations

• Make it easier to add new code: when adding a new feature, we can use two approaches, none of which is right or wrong:
• either code it quickly without regard to how well it fits with an existing design, refactor later;
• or modify the existing design so it can easily and gracefully accommodate the new feature.
• Improve the design of existing code: sniff constantly for code smells and remove smells immediately (or soon) after finding them. This is a great hygienic habit. It can also lead to greater job enjoyment.
• Gain a better understanding of code: If some code is not clear, it's an odor that needs to be removed by refactoring, not by deodorizing the code with a comment.
• Make coding less annoying: We often refactor simply to make code less annoying to work with.

Many Eyes

To get best refactoring results, you'll want the help of many eyes, which is one of the reasons for the practices of pair-programming and collective code ownership.

Human-Readable Code

Good code 

• reads like spoken language
• separates important code from distracting code

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." [Martin Fowler]

Keeping Code Clean

Refactoring is a lot like cleaning your room. The worse the mess becomes, the harder it is to clean and the less you want to clean it. One giant cleanup is not enough, you must practice continuous hygiene. To keep code clean, we must continuously:

• remove duplication
• simplify code
• clarify code

Do not tolerate messes in code, and do not backslide into bad habits.

Clean code -> Better design -> Faster development -> Happy customers and programmers 

Small Steps

Take very small steps and keep the unit tests green! They should not stay red for more than a few minutes.

Design Debt

Design debt is a much better metaphor to communicate with management than the technical language of refactoring. It occurs when you do not consistently do 3 things:

1. Remove duplication
2. Simplify your code
3. Clarify your code's intent

When do you pay back the debt? In financial terms, when you don't pay your debt, you incur late fees. If you don't pay your late fees, you incur higher late fees, and so on. Compound interest kicks in, and going out of debt becomes an impossible dream. So it is with design debt.

Evolving a New Architecture 

Evolutionary design suggest that you:

• Form one team
• Drive the framework from application needs
• Continuously improve applications and the framework by refactoring

Composite and Test-Driven Refactorings

Composite refactorings are high-level refactorings composed of low-level refactorings. Between applying low-level refactorings you run unit tests.

Test-driven refactorings involove applying TDD to produce replacement code and then swap out old code for new code (while retaining and rerunning the old code's tests).

When it's impossible to evolve a design through composite refactorings, test-driven refactorings can be used to produce a better design. Substitute Algorithm is a good example of a test-driven refactoring.

Benefits of composite refactorings:

• They describe an overall path for a refactoring sequence
• They suggest non-obvious design directions
• They provide insights into implementing patterns