Drawing on the original Refactoring book that used Java as the programming language for examples, this new edition of Refactory Ruby explains how to apply refactoring techniques in a Ruby context, adding some refactoring that are specific to this language.
Instead of trying to give a definition of refactoring, the book begins with a long example of practicing refactoring. The second chapter explains the who, why and when of refactoring. The third chapter is dedicated to “smells”, hints in Ruby code that should tell you it needs to be refactored. The following chapter of this book discusses the importance of tests in refactoring.
The end of the book contains a catalog of refactorings with a chapter dedicated to the “big” refactorings, the one that combine many individual “moves”. A final chapter is dedicated to the “philosophy” of refactoring, discussing topics like when you should stop doing it.
I will strongly recommend this book to all ruby programmers, but every developer that uses an object-oriented language could benefit from it to learn and apply refactoring.
Reference: “Refactoring Ruby Edition”, Jay Fields, Shane Harvie, Martin Fowler, Kent Beck, Addison-Wesley
Quotes
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence when you refactor you are improving the design of the code after it has been written.
When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.
In the end, all the earlier points come down to this: Refactoring helps you develop code more quickly. […] I strongly believe that good design is essential for rapid software development. […] Without a good design, you can progress quickly for a while, but soon the poor design starts to slow you down. You spend time finding and fixing bugs instead of adding new function.
Don’t let the fear that testing can’t catch all bugs stop you from writing the tests that will catch most bugs.
For goodness’ sake, refactor with someone.
The final thought I leave you with is this: Never forget the two hats: The refactoring hat, and the new functionality hat. Only wear one hat at a time.