I have read the original Refactoring back in 2006 but I didn’t own a copy so due to my infatuation for the Ruby programming language I decided to buy a copy of Refactoring Ruby Edition.
The first chapter introduce refactoring through a vert explicative example.
The second chapter explore the core principles and origins of refactoring.

It is interesting how refactoring is one of the core practices that Kent Beck and Ward Cunningham used on the famous C3 project and that then became part of the arsenal of the extreme programming’s practices.

Due to the iterative nature of extreme programming, a big up front design is unfeasible. Refactoring, unit testing and good object oriented practices allow to have a code that is easy, cheap and safe to change.

An another important point discussed in this chapter is when to refactor. The answer suggested is very similar to what I practice daily:

• Refactor when it helps to introduce a new feature
• Refactor when fixing a bug
• Refactor for better understanding

The most valuable tip is the rule of 3:

The first time, you just do something. The second time, you do something similar you wince at the duplication but you do it anyway. The third time, you refactor.

One last point touched in the chapter was the impact of refactoring on software performance. There are several refactorings (e.g. Remove Temp with Query) that hinder performance. Martin Fowler states that ad hoc and localized performance improvement are expensive and sometimes counterproductive. We should always remember to make the software right and easy to change so that we can improve performance later where the bottlenecks lie. I think this seek for performance everywhere is a cognitive bias that we inherited from the time when developers had to deal with few Ks of memory and expensive processor time.

So far Refactoring Ruby Edition has been enjoyable and I’m looking forward to learn how to refactor in a more disciplined and cautious way.