[harlow]

> Overly short methods can make code much harder to read and follow and actually increase complexity, because now there are many more entry points.

Ideally there wouldn't be any more entry points. If we create multiple short well-named private methods they should make it easier to follow your code. Side benefit of well-named methods is they can act as simple documentation for readers.

> Case statements can be a bad code smell, just as is_a?(...), but not in every situation.

More often than not when doing a code review a case statement will catch my eye. Often they are OK, but more often than not they can be avoided.

> Read "Design Patterns" by the GoF and "Refactoring" by Martin Fowler also.

So important to read these. They are great for all developers. The idea behind Ruby Science is to show how to use these techniques in a Ruby on Rails application. With real code, and real refactoring (along with code, and a history of git Commits to show the exact changes we're making).