What do you think?
Rate this book
Refactoring at Scale: Regaining Control of Your Codebase
Making significant changes to large, complex codebases is a daunting task--one that's nearly impossible to do successfully unless you have the right team, tools, and mindset. If your application is in need of a substantial overhaul and you're unsure how to go about implementing those changes in a sustainable way, then this book is for you. Software engineer Maude Lemaire walks you through the entire refactoring process from start to finish. You'll learn from her experience driving performance and refactoring efforts at Slack during a period of critical growth, including two case studies illustrating the impact these techniques can have in the real world. This book will help you achieve a newfound ability to productively introduce important changes in your codebase.
243 pages, Paperback
Published November 17, 2020
24 people are currently reading
184 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 8 of 8 reviews
January 18, 2021
I started work as a new grad software engineer during Covid, and I've been struggling with developing soft skills remotely. I find cross-functional communication and technical writing challenging. This book felt like months of mentorship, and it's a guide I will return to for years to come. Lemaire's writing is concise and charming, providing actionable, novel suggestions for every part of the refactoring process. I applied every chapter to a recent project of mine, and I had several aha moments, where I wish I had read this book before the project. Even if you aren't start a refactoring project soon, the majority of her tips apply to working better in general, though, such as setting communication boundaries, creating a project execution plan, and learning how to pull levers of influence in your workplace. Communication is such a vital part of any software-adjacent role, and this book makes any sticky situation feel less daunting.
April 22, 2021
I am convinced that developers and technical managers should strengthen their refactoring practice. Indeed, unless you change companies every couple years, each time starting with a new project from scratch, large scale refactoring will be part of the life of the teams one day or another. It can be risky (as in killing you company or more frequently costing unnecessary time and energy).
Martin Fowler's classic book Refactoring is more about code smells and examples of code rewrites, so I wanted to learn more about the higher level aspects with Refactoring at Scale.
The book details throughout the chapters a methodology for refactoring projects. It comes from the author's experience, especially at Slack, which has, with its phenomenal growth, had to address a number of them.
The skeleton of the methodology is detailed in the book (after a first introduction part), consisting of:
Planning phases
1/ Measuring a starting state: gathering metrics assessing the problem, why the refactor must be executed and when is the best time (eg code complexity metrics, formal/informal documentation, version control, pain points chatting with colleagues...)
2/ Drafting a plan: defining an end state for the metrics, choosing a strategy, defining and estimating milestones, choosing a rollout/rollback strategy. At that point, you should have a plan to share with other teams for reviewing. It should gather the why / when / who / what, list all phases and for each one: a todo list, an estimate, start metrics and goal metrics.
3/ Getting buy-in
4/ Building the right team
Execution phases
5/ Communicating: communicating both with and outside the team during the project
6/ Executing: this chapter describes a technique used at Slack called "dark mode / light mode" to compare pre-refactor and post-refactor behavior. It consists in several phases. First, during dark mode, both old and new implementations are called, the results are compared / logged if different, and the results from the old implementation are returned. It helps finding bugs/regressions in the new implementation. Second, after bugs are fixed, next phase (light mode) kicks in, starting with a subset of low risks users then progressively more and more of them. In this phase, both implementations are still called / logged but this time results from the new implementation are returned. Finally, old implementation is removed.
7/ Making the refactor stick: workshops, office hours, documentation, linters to make sure the refactor is widely known in the company and in some cases well used
What I liked
- the principle of using metrics to objectify the success of the project (classic in product management, less in purely technical projects)
- the dark mode/light mode pattern, simple and beautiful (see on this subject the "scientist" library developed by GitHub)
- the two cases studies at the end of the book (a database schema change and a database engine migration). They are much more detailed than blog posts, more transparent and authentic also about the mistakes made too (remember that many technical blog posts have a marketing objective of recruitment... and forget to mention some details)
What I didn’t like
- Some parts were too long, some too basic
- I was hoping for some material on the thorny subject of "big rewrites", technical debt management, different migration strategies
- The passage on how to "sell" the project to the manager inviting giving an ultimatum and threatening to leave the company. For me, this is a huge NO, it can totally break confidence.
Highlights
"Confidence in your ability to refactor allows you to lean toward action and start building a system sooner, well before you’ve developed a strong understanding of all the moving pieces, pitfalls, and edge cases."
"The most common culprits behind tech debt are limited time, limited numbers of engineers, and limited money. (...) Although it can be easy to point a finger at the original authors of the code and admonish them for making decisions that appear suboptimal today, it’s important to remember that they were operating under serious constraints."
"Be cautious of conversations in which colleagues say something like, “While we’re at it we could…” or “I’ve always wanted X to also handle…”. Unless you’re well-versed in the art of saying “no,” you might end up agreeing to do more than you originally anticipated."
"Most large-scale refactors have sizable milestones consisting of tedious, repetitive work. (All of the examples in this book to date have one or two lengthy, monotonous steps.) These milestones tend not to be exceptionally challenging or engaging; they’re dull but necessary. When the team needs to execute these stages, usually the project starts to feel as though it has slowed to a crawl. Teammates can be more prone to burnout during these stages, but having a group of individuals you can lean on, with which you can share your frustrations, can make a world of difference."
"I highly recommend developers begin their code archeology expedition before they begin to execute their refactoring effort, because the added context can give a different shape and direction to the project."
Martin Fowler's classic book Refactoring is more about code smells and examples of code rewrites, so I wanted to learn more about the higher level aspects with Refactoring at Scale.
The book details throughout the chapters a methodology for refactoring projects. It comes from the author's experience, especially at Slack, which has, with its phenomenal growth, had to address a number of them.
The skeleton of the methodology is detailed in the book (after a first introduction part), consisting of:
Planning phases
1/ Measuring a starting state: gathering metrics assessing the problem, why the refactor must be executed and when is the best time (eg code complexity metrics, formal/informal documentation, version control, pain points chatting with colleagues...)
2/ Drafting a plan: defining an end state for the metrics, choosing a strategy, defining and estimating milestones, choosing a rollout/rollback strategy. At that point, you should have a plan to share with other teams for reviewing. It should gather the why / when / who / what, list all phases and for each one: a todo list, an estimate, start metrics and goal metrics.
3/ Getting buy-in
4/ Building the right team
Execution phases
5/ Communicating: communicating both with and outside the team during the project
6/ Executing: this chapter describes a technique used at Slack called "dark mode / light mode" to compare pre-refactor and post-refactor behavior. It consists in several phases. First, during dark mode, both old and new implementations are called, the results are compared / logged if different, and the results from the old implementation are returned. It helps finding bugs/regressions in the new implementation. Second, after bugs are fixed, next phase (light mode) kicks in, starting with a subset of low risks users then progressively more and more of them. In this phase, both implementations are still called / logged but this time results from the new implementation are returned. Finally, old implementation is removed.
7/ Making the refactor stick: workshops, office hours, documentation, linters to make sure the refactor is widely known in the company and in some cases well used
What I liked
- the principle of using metrics to objectify the success of the project (classic in product management, less in purely technical projects)
- the dark mode/light mode pattern, simple and beautiful (see on this subject the "scientist" library developed by GitHub)
- the two cases studies at the end of the book (a database schema change and a database engine migration). They are much more detailed than blog posts, more transparent and authentic also about the mistakes made too (remember that many technical blog posts have a marketing objective of recruitment... and forget to mention some details)
What I didn’t like
- Some parts were too long, some too basic
- I was hoping for some material on the thorny subject of "big rewrites", technical debt management, different migration strategies
- The passage on how to "sell" the project to the manager inviting giving an ultimatum and threatening to leave the company. For me, this is a huge NO, it can totally break confidence.
Highlights
"Confidence in your ability to refactor allows you to lean toward action and start building a system sooner, well before you’ve developed a strong understanding of all the moving pieces, pitfalls, and edge cases."
"The most common culprits behind tech debt are limited time, limited numbers of engineers, and limited money. (...) Although it can be easy to point a finger at the original authors of the code and admonish them for making decisions that appear suboptimal today, it’s important to remember that they were operating under serious constraints."
"Be cautious of conversations in which colleagues say something like, “While we’re at it we could…” or “I’ve always wanted X to also handle…”. Unless you’re well-versed in the art of saying “no,” you might end up agreeing to do more than you originally anticipated."
"Most large-scale refactors have sizable milestones consisting of tedious, repetitive work. (All of the examples in this book to date have one or two lengthy, monotonous steps.) These milestones tend not to be exceptionally challenging or engaging; they’re dull but necessary. When the team needs to execute these stages, usually the project starts to feel as though it has slowed to a crawl. Teammates can be more prone to burnout during these stages, but having a group of individuals you can lean on, with which you can share your frustrations, can make a world of difference."
"I highly recommend developers begin their code archeology expedition before they begin to execute their refactoring effort, because the added context can give a different shape and direction to the project."
February 10, 2022
A book about how best to prepare and execute big refactoring efforts. It highlights that refactoring is more then just rewriting code, it is about the right steps to prepare refactoring (getting the managers onboard, hiring the right team, test coverage), good communication while refactoring so that all dependent teams know how the refactoring will impact their work process, updating highups about the struggles and progress, and much more.
April 22, 2021
This book is not technical, it assumes you already know how to refactor. It is a book of how to refactor in a realistic environment, not in a vacuum, with code that nobody and everyone owns at the same time. The political pitfalls, why your manager is likely to refuse and strategies to convince management about the value and urgency of refactoring. This book is definitely for someone in roles similar to team lead or application architect, but as you read it, it seems addressed to non-senior engineers which seems a bit unrealistic.
It is not exactly an engaging read, but the advice is useful, and you can use it as reference as you begin and execute the project. Most of the advice is applicable to any type of project you want to work on and you are not getting buy-in from management.
It is not exactly an engaging read, but the advice is useful, and you can use it as reference as you begin and execute the project. Most of the advice is applicable to any type of project you want to work on and you are not getting buy-in from management.
September 17, 2024
The book provides you with knowledge on how to refactor live projects. I could not say that I benefited from this book - if you have some experience working on a large codebase in a team - you probably will know core ideas, such as how to plan refactor, team communication and organization, etc. I really liked particular chapters on team communication as I have faced these issues with my past assignments. Also, I liked the case studies section. But, in general, I could not give to this book a very high rating - it didn't provide me with something new, rather systematized what I knew already from practice. 3/5 or 6/10 if you wish.
July 6, 2024
A good explanation on all the work that needs to go into the strategic and management aspect of a large refactoring. It is a great addition to the book Refactoring: Improving the Design of Existing Code by Martin Fowler.
June 25, 2023
Very detailed, good explanation of a big refactorings management approaches. Slack real-case scenarios are more then appreciated. I recommend the book to everyone who is going to conduct refactorings of any scale
Displaying 1 - 8 of 8 reviews