Refactoring Ruby Edition Chapter 2: Principles in Refactoring

David — Sun, 07 Mar 2010 18:03:23 +0000

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.

TDD: When does ‘Good Enough Code’ become not good enough?

David — Mon, 25 Jan 2010 21:47:49 +0000

Today I started try to refactor a piece of code that was causing me pain.
Dependencies were tangled together, classes were getting bigger, functions and names were losing their meaning and unit tests were becoming cluttered and hard to understand.
After few hours trying to tangle this code I started thinking that probably it would have been easier if we had tackled that a few features earlier.
When you are caught in the TDD cycle red – green – refactor it’s easy to focus only on small scale refactoring and losing the big picture. Also Bob Martin rule: “You may not write more production code than is sufficient to pass the current failing test.” might be misleading.
Dan North talks of “…deferring important architectural and design decisions until the last responsible moment”.
Is there an easy way to identify the last responsible moment?
I think for now on I will stick to this rule: as soon as I start adding a feature to a piece of code I will make sure that it respect fundamentals good practices (small functions that do one thing, command query separation, small classes that follows the single responsibility principle and meaningful names). I will applly the same treatment to tests.
I will probably spend more time caring about exception handling, good object modeling and so on, on the most used and strategic part of a codebase.
In order to identify those areas, keeping track on stories that takes longer than expected and the one with more bugs, might help.
What is your approach to this problem?

In the meanwhile you should follow me on twitter here

David Santoro » refactoring

Refactoring Ruby Edition Chapter 2: Principles in Refactoring

TDD: When does ‘Good Enough Code’ become not good enough?