Refactoring: Improving the Design of Existing Code by Martin FowlerMy rating: 4 of 5 stars
Context & Why I read this book
I am a software engineer with a focus on mobile applications and was looking for a more systematic approach to safely rewriting code without causing regressions. Such methodical "refactoring" is a valuable skill for developers; especially in enterprise settings where one works on large codebases with many contributors. Further, Addison Wesley & Martin Fowler are renowned in the field of software construction.
What is the book about as a whole?
The author himself says that this is a guide for professional programmers on how to refactor code "in a controlled and efficient manner". He explains what refactoring is (and what not), how to do it properly and he gives many detailed and step-by-step code refactoring examples using the programming language JavaScript. (This review is about the second edition of the book, which appeared 18 years after the first edition, which used Java for code samples)
The book's structure
The book is divided into 12 chapters:
1. Refactoring, a First Example(the author deliberately leads with a very practical introduction instead of a theoretical one)
2. Principles in Refactoring(a more general and theoretical introduction to the concept of changing software systems without causing regressions)
3. Bad Smells in Code(a list of indications that show you _when_ to apply refactoring; unfortunately no code samples in this section)
4. Building Tests(A dedicated section on automated testing, since refactoring cannot be done without an appropriate test suite)
5. Introducing The Catalog
6. A First Set of Refactorings
7. Encapsulation
8. Moving Features between Objects
9. Organizing Data
10. Simplifying Conditional Expressions
11. Refactoring APIs
12. Dealing with Inheritance
Chapters 6-12 make up the "refactoring catalog", which contains 67 "refactorings" with names like:
- "Change Function Declaration"
- "Extract Function"
- "PullUp Method"
- "Replace Loop with Pipeline"
Each Refactoring contains a small graphic to memorize the refactoring, followed by a short and glanceable code example and a section on the motivation of the particular refactoring. Then there is the main part: a section called "mechanics" which is a detailed list of usually 5-12 steps on how to approach the given Refactoring followed by a detailed example with sample code.
The physical book comes with a free digital web version included.
One lesson
Rather than mentioning a particular refactoring or concrete advice from the book I want to take the lesson with me, that "Refactoring" is no island and only works properly in combination with self-testing code (automated tests), trunk based development (or continuous integration) and the general philosophy of opportunistically improving a code base little by little.
Reading Recommendation / Who should read this?
I think, that this book (in its second edition!) makes a good and valuable contribution by showing you that there is a more methodical and structured way of changing code. The book will not render you a refactoring expert since most of it (the catalog) is meant for reference instead of up-front learning (while containing many code samples, there are no exercise or challenges to solve and Fowler himself refers to William C. Wake'" Refactoring Workbook this regard). But even if it did, according to my limited experience in the field, in many (if not most) enterprise settings with legacy codebases and large teams there is not much hope that introducing this will ever work (see my lesson above). So while at the moment I don't see much practical relevance for myself I still consider it worthwhile to read this book for software engineers. Also, if you think this is wrong and your company successfully applies this, pls hire me.
All in all a 7 out of 10 (⭑⭑⭑⭑) on my personal rating scale ("Good read, despite minor weaknesses; generally recommended.")
-----------
View all my reviews on Goodreads