I don’t read books to keep up-to-date with the latest industry changes but to improve myself as a software developer. Throughout the previous year my reading focus has been on clean code. However, the sheer mass of software development books makes it difficult to find the really good reads. By reviewing a few of those books, I can reflect on what I’ve learned and at the same time point out interesting publications for you.
The oldest book I’ve read has been Martin Fowler’s classic “Refactoring – Improving the Design of Existing Code” from 1999. The book consists of three parts: an introduction to refactoring, a catalog of refactoring patterns and some hands-on information at the end.
Even if you already know a lot about refactoring and the most common refactoring patterns are natural to you, it is worth the time for various reasons. First, over the course of the book it cements the fine art of detecting code smells and eliminating them with a series of small, step-by-step refactorings. Second, chapter three lists code smells and more importantly: it includes a list of good names for them. This allows developers to easily communicate to colleagues what kind of smell a particular part of code suffers from. Finally, after reading the book you’re sure that good test coverage is an absolute necessity. Only broad coverage ensures that refactorings can be performed without fearing broken code.
The second part of the book has been more of a refreshment for me; also the detailed description of how to perform a particular refactoring step-by-step is not too interesting nowadays: we are blessed with tooling that automatically performs the refactoring for us in a safe way. Side note: it is funny how Martin Fowler predicts refactoring tools and their usefulness way back in 1999. Finally, part three presents a big refactoring example which makes use of multiple patterns, one after the other, to improve the code quality gradually. This helps less experienced developers to go from “huge redesigns” to “step-by-step improvements by refactoring” – in my opinion a very important step to take. In the end a “reality check” chapter gives advice about when and how often you should refactor.
Prerequisites? You should already have profound programming knowledge and should at least know one of the “three big” OO languages: C++, Java or C# (the examples in the book are written in Java).
Should you read the book? Any serious developer nowadays knows at least a bit about refactoring. This book is good to solidify existing knowledge and to find out why, when and where exactly you should refactor code to improve overall code quality. Experienced developers should pick out selected chapters to get a deeper understanding of the matter.