What do you think?
Rate this book
99 Bottles of OOP
"Everybody complains about the weather but nobody does anything about it." Likewise, everyone has an opinion about what good code looks like, but those opinions don't help you create it. This book fills that gap. It explains the process of writing good code, and teaches you to achieve beautifully programmed ends by way of extremely practical means.
What It's About
99 Bottles of OOP is a practical guide to writing cost-effective, maintainable, and pleasing object-oriented code.
It explores:
Recognizing when code is "good enough"
Getting the best value from Test-Driven Development (TDD)
Doing proper refactoring, not random "rehacktoring"
Locating concepts buried in code
Finding names that convey deeper meaning
Safely altering code by following the "Flocking Rules"
Simplifying new additions with the Open/Closed Principle
Avoiding conditionals by obeying the Liskov Substitution Principle
Making targeted improvements by reducing Code Smells
What Makes It Unique?
We are practical people. We love beautiful code but we're committed to getting things done. 99 Bottles of OOP enables both of these desires. It teaches a practical technique for getting things done that leads, naturally and inevitably, to beautiful code.
This book contains an extended refactoring, and it details the rationale behind every change. It is a hands-on workbook rather than a list of theoretical ideas. It explains how to use the principles of object-oriented design to guide, not just the final arrangement of code, but each decision about what line of code to write next.
It teaches the theory of what good OO looks like, but even better, it supplies step-by-step guidance about how to achieve it.
Who Should Read It?
The lessons work for programmers with a broad range of experience, from rank novice to grizzled veteran. The code examples are written in Ruby, but this book is not about Ruby--it's about object-oriented programming and design. Regardless of your background, applying these techniques will make your code easier to understand, simpler to change, and more satisfying to contemplate.
What It's About
99 Bottles of OOP is a practical guide to writing cost-effective, maintainable, and pleasing object-oriented code.
It explores:
Recognizing when code is "good enough"
Getting the best value from Test-Driven Development (TDD)
Doing proper refactoring, not random "rehacktoring"
Locating concepts buried in code
Finding names that convey deeper meaning
Safely altering code by following the "Flocking Rules"
Simplifying new additions with the Open/Closed Principle
Avoiding conditionals by obeying the Liskov Substitution Principle
Making targeted improvements by reducing Code Smells
What Makes It Unique?
We are practical people. We love beautiful code but we're committed to getting things done. 99 Bottles of OOP enables both of these desires. It teaches a practical technique for getting things done that leads, naturally and inevitably, to beautiful code.
This book contains an extended refactoring, and it details the rationale behind every change. It is a hands-on workbook rather than a list of theoretical ideas. It explains how to use the principles of object-oriented design to guide, not just the final arrangement of code, but each decision about what line of code to write next.
It teaches the theory of what good OO looks like, but even better, it supplies step-by-step guidance about how to achieve it.
Who Should Read It?
The lessons work for programmers with a broad range of experience, from rank novice to grizzled veteran. The code examples are written in Ruby, but this book is not about Ruby--it's about object-oriented programming and design. Regardless of your background, applying these techniques will make your code easier to understand, simpler to change, and more satisfying to contemplate.
225 pages, ebook
Published January 1, 2016
110 people are currently reading
1,874 people want to read
About the author
Sandi Metz
4Ìýbooks190ÌýfollowersSandi Metz is a programmer, teacher, author, and sometime consultant. In the past 30+ years she has written innumerable applications and creates practical solutions that produce working software that is easy to change. She has spoken about object-oriented design and refactoring at international Ruby conferences since 2009.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 75 reviews
May 13, 2017
This is not just a book on OOP, it’s basically a full blown OOP course you can follow along at your own pace wherever you are. The domain is so simple that anybody can grasp it in a very short time, no need to know anything about bikes - looking at you, POODR� :D
The whole thing is quite ambitious, as Sandi and Katrina say in the preface “it turns out that everything you need to know about Object-Oriented Design (OOD) can be learned from the 99 Bottles of Beer song. Well, perhaps not everything, but quite certainly, a great many things.�
The promise is kept: the authors manage to send across a whole lot of learnings, both practical and more abstract with a very simple problem and that’s why I loved this book so much!
Here are some of the key points for me:
- learn to embrace simplicity and refrain from designing too much too soon! Making abstractions is hard and it’s easy to get it wrong, especially when you make them too soon. Ask yourself if a simpler solution is good enough for the current requirements!
- is your code understandable?? Sometimes we spend more time reading code (even our own) than writing it, making your code ‘speak the domain� is the best thing you can do for you and your collaborators.
- are your tests slowing you down and getting in your way? “Tests are not the place for abstractions—they are the place for concretions.�
- how do you implement a new requirement when your code is completely closed to said requirement and you have no idea how to make it open? Sandi and Katrina have got recipes and techniques for you.
And these are only a few of the get aways from this book. The fact that the authors manage to make you have fun while learning is a huge plus too :)
The whole thing is quite ambitious, as Sandi and Katrina say in the preface “it turns out that everything you need to know about Object-Oriented Design (OOD) can be learned from the 99 Bottles of Beer song. Well, perhaps not everything, but quite certainly, a great many things.�
The promise is kept: the authors manage to send across a whole lot of learnings, both practical and more abstract with a very simple problem and that’s why I loved this book so much!
Here are some of the key points for me:
- learn to embrace simplicity and refrain from designing too much too soon! Making abstractions is hard and it’s easy to get it wrong, especially when you make them too soon. Ask yourself if a simpler solution is good enough for the current requirements!
- is your code understandable?? Sometimes we spend more time reading code (even our own) than writing it, making your code ‘speak the domain� is the best thing you can do for you and your collaborators.
- are your tests slowing you down and getting in your way? “Tests are not the place for abstractions—they are the place for concretions.�
- how do you implement a new requirement when your code is completely closed to said requirement and you have no idea how to make it open? Sandi and Katrina have got recipes and techniques for you.
And these are only a few of the get aways from this book. The fact that the authors manage to make you have fun while learning is a huge plus too :)
July 8, 2017
Much like Kent Beck's TDD book, 99 Bottles is a chance to pair program with Sandi and Katrina. During the programming, you'll discover at least four fundamental techniques for refactoring, each of which justifies the purchase, along with concrete examples of how to apply the concepts to real code. I recommend this book to all object-oriented programmers, whether you are using Ruby (as per the specific examples in the book) or C#, Java, TypeScript, PHP, et al.
December 31, 2020
Sandy Metz already had one of the best books in Object-Oriented with the Practical Object-Oriented Design book. Now she has 2 books.
This is one of the few books that don't push testing to an Appendix. TDD is the part of the book that enables all the subsequent refactorings. It may seem as a lot of work to follow each small step but I suggest you read the book with the editor at your side and try them after each chapter and without looking them up. The Flocking Rules seem too simple to work albeit they do! Every time. Refactoring will feel, suddenly, natural.
This book teaches how to be patient and pay extreme attention. You'll grasp how to remove duplication by focusing on higher level abstractions instead of simply text that look alike. And at each step the domain will get crispier. There will be new concepts that had been hidden and are now clear by simply applying the refactoring steps tirelessly.
You'd also understand, at the end of the book, why you should refactor before working in a new feature and not after: it will make the feature way easier and clearer for future readers.
This book only get one thing wrong: it states that TDD finally got mainstream. Sadly, that's far from being true.
This is one of the few books that don't push testing to an Appendix. TDD is the part of the book that enables all the subsequent refactorings. It may seem as a lot of work to follow each small step but I suggest you read the book with the editor at your side and try them after each chapter and without looking them up. The Flocking Rules seem too simple to work albeit they do! Every time. Refactoring will feel, suddenly, natural.
This book teaches how to be patient and pay extreme attention. You'll grasp how to remove duplication by focusing on higher level abstractions instead of simply text that look alike. And at each step the domain will get crispier. There will be new concepts that had been hidden and are now clear by simply applying the refactoring steps tirelessly.
You'd also understand, at the end of the book, why you should refactor before working in a new feature and not after: it will make the feature way easier and clearer for future readers.
This book only get one thing wrong: it states that TDD finally got mainstream. Sadly, that's far from being true.
August 13, 2019
I honestly don't get the average 4.6 rating.
I believe this book gives the illusion of understanding what to do with code that doesn't seem right, but that in a realistic situation it would not be helpful.
One of the more frustrating things about programming is that some people "get it" and others don't. This book follows Fowler's closely and is a proponent of its idea of using "code smells," which are a catalog of potentially bad coding practices. These can help, but there's some step of understanding that needs to happen. The only way I know to make this transition to occur is via practice and feedback, and it doesn't always take.
I read this book as a way to evaluate whether it was a good one to recommend to people needing to take the next step with their programming skills, and I've concluded that it is not. I fear that it would lead people down a long path of refactoring code, ending with something not much better than it was at the beginning.
There are many positive things about this book, however. It emphasizes writing for understandability. (It promotes its "shameless green" solution as a good example of that, but I don't believe its final implementation is judged with the same outlook as the straw man examples in chapter 1.) It gives good step-by-step instructions for changing code without breaking it, which is a valuable skill to learn. It also advocates for immutability and "fast enough" code, which are good ways to simplify.
Ultimately, despite the fact that this is a book-length treatment of design and refactoring, I think that it suffers from the problem that the task is too simple to be realistic. This makes it hard to judge the value of its prescriptions.
I feel like it's given me some things to chew on. For example, I plan to experiment with being more strict about separating refactoring from modifying code in my own programming work. I also plan to revisit Refactoring. But, I'm not going to send this book to new programmers.
I believe this book gives the illusion of understanding what to do with code that doesn't seem right, but that in a realistic situation it would not be helpful.
One of the more frustrating things about programming is that some people "get it" and others don't. This book follows Fowler's closely and is a proponent of its idea of using "code smells," which are a catalog of potentially bad coding practices. These can help, but there's some step of understanding that needs to happen. The only way I know to make this transition to occur is via practice and feedback, and it doesn't always take.
I read this book as a way to evaluate whether it was a good one to recommend to people needing to take the next step with their programming skills, and I've concluded that it is not. I fear that it would lead people down a long path of refactoring code, ending with something not much better than it was at the beginning.
There are many positive things about this book, however. It emphasizes writing for understandability. (It promotes its "shameless green" solution as a good example of that, but I don't believe its final implementation is judged with the same outlook as the straw man examples in chapter 1.) It gives good step-by-step instructions for changing code without breaking it, which is a valuable skill to learn. It also advocates for immutability and "fast enough" code, which are good ways to simplify.
Ultimately, despite the fact that this is a book-length treatment of design and refactoring, I think that it suffers from the problem that the task is too simple to be realistic. This makes it hard to judge the value of its prescriptions.
I feel like it's given me some things to chew on. For example, I plan to experiment with being more strict about separating refactoring from modifying code in my own programming work. I also plan to revisit Refactoring. But, I'm not going to send this book to new programmers.
April 26, 2021
It very valuable book about good programming habits. It concise, comprehensible and example clean.
Inside book you can find ridiculously small code example that reveal so much about TDD, refactoring, naming. Maybe all ideas a familiar to experienced programmers, but I must recognize the way all this ideas are applied in this book. The way author reveal new techniques are brilliant.
Inside book you can find ridiculously small code example that reveal so much about TDD, refactoring, naming. Maybe all ideas a familiar to experienced programmers, but I must recognize the way all this ideas are applied in this book. The way author reveal new techniques are brilliant.
June 10, 2019
A whole course within a book. Written in a friendly, accessible tone, it tells a story and walks you through every single code decision. There's also some good general life lessons subtly sprinkled throughout.
I wish ALL technical books were written like this.
I did a podcast that discussed this book (so this was a re-read of Chapters 1-5). When we were discussing it, Chapter 6 hadn't yet been released —we were on the bleeding edge! ;-) � hence why we stopped! Check it out if you want a study companion: .
I wish ALL technical books were written like this.
I did a podcast that discussed this book (so this was a re-read of Chapters 1-5). When we were discussing it, Chapter 6 hadn't yet been released —we were on the bleeding edge! ;-) � hence why we stopped! Check it out if you want a study companion: .
August 14, 2022
I read the first edition and now I'm happy to finish the second too. It is a great book. I'm glad I read it twice.
September 24, 2021
One of the best books that illustrate concepts in easy and simple way.
July 26, 2019
99 Bottles of OOP is a good book that shows us how to write OOP code through an example. I like the fact that it focuses on a single problem - printing the entire "99 bottles of beer" song. This problem is simple, yet complex enough to showcase the principles and practices that can get us to clean code. It emphasizes the importance of simplicity in code and how to get to an Open design by removing one code smell at a time. I think the book's highlight are the Flocking Rules: selecting things that are most alike, finding the difference between them and removing that difference. I like the author's writing style - it's easy to follow and full of examples. This book allows us to see how they're approaching a coding problem.
November 29, 2019
Don't get me wrong, the book is good but come on. How much can you optimise a very simplistic problem? At some point it become ridiculous and more confusing.
For example, at some point in chapter 4 there is a function that supposed to represent a noun and is coded like:
def pronoun(number)
if number == 1
"it"
else
"one"
end
end
This is very confusing. What it means if number is 1 return "it" and anything else return "one"? Really?. That would not pass a code review.
And then the author continues to optimise until it creates a monstrosity in Listing 4.29: 1 which does not really make sense to have in the first place. In my opinion the author should have stopped right after the Shameless Green code and started with a different example. I stopped considering any code after that as it looked over engineered.
Maybe you ca read it as a personal diary but please, don't apply it to production.
For example, at some point in chapter 4 there is a function that supposed to represent a noun and is coded like:
def pronoun(number)
if number == 1
"it"
else
"one"
end
end
This is very confusing. What it means if number is 1 return "it" and anything else return "one"? Really?. That would not pass a code review.
And then the author continues to optimise until it creates a monstrosity in Listing 4.29: 1 which does not really make sense to have in the first place. In my opinion the author should have stopped right after the Shameless Green code and started with a different example. I stopped considering any code after that as it looked over engineered.
Maybe you ca read it as a personal diary but please, don't apply it to production.
September 24, 2017
If there’s any fault with little book on object-oriented programming, it’s that it sometimes feels slow—especially if you already know where’s it’s headed. But that’s exactly what makes it great. It goes through the logic of every step in the thought process—even parts that are “easier done than said.� There’s nothing left to mysterious hand-waving here.
I’m going to go on record and predict that this will be a classic. It brings clarity to many of the misunderstandings that continue to surround OO ideas.
I’m going to go on record and predict that this will be a classic. It brings clarity to many of the misunderstandings that continue to surround OO ideas.
January 18, 2017
Very clear writing and step-by-step walkthrough of refactoring, with explanations for why to make certain choices. If you get a chance to take her in-person workshop, definitely do that, but this is a good companion resource if you don't have that opportunity or need a refresher.
August 4, 2022
Pretty basic but nevertheless useful for those who believe "OOP" is something with a meaningful definition and that some piece of "OO" code can be less shit than another.
-1 for making fun of the idea that the real world is immutable.
-1 for making fun of the idea that the real world is immutable.
February 9, 2018
Reads like a detective novel.
Practical, detailed and very easy to understand.
Practical, detailed and very easy to understand.
September 2, 2024
Context: I read the Ruby edition of this book.
This is a great book for really grasping the fundamentals of object-oriented programming and learning how to pair it with test-driven development. While the book focuses on OOP, it does espouse the importance of TDD and its benefits as well. As someone who's primarily learned OOP from doing rather than focusing on theory, I found this book to be great for filling in many of the holes and conceptual shortcomings that I faced as a result of my previous methodologies.
All that being said, there are a couple things preventing me from giving this a 5/5. While complaining about the difficulty of vocabulary being used in a book may come off as a bit dumb, this book felt a bit verbose at times and included words that I felt made it unnecessarily difficult to understand. For example, are words like 'vociferously,' 'ameliorate,' or 'parochial' really necessary in a book about programming concepts? Additionally, there were a couple instances where Metz utilized some questionable syntax that she herself admitted is generally frowned upon. In her defense, this is a book that's intended to be about theory, and there are plenty of other resources if syntax is your primary focus.
Overall, I'd give this book a solid 8/10. In addition to strengthening your knowledge of OOP, you can expect to come out of this book with a deeper understanding of the English language as well.
This is a great book for really grasping the fundamentals of object-oriented programming and learning how to pair it with test-driven development. While the book focuses on OOP, it does espouse the importance of TDD and its benefits as well. As someone who's primarily learned OOP from doing rather than focusing on theory, I found this book to be great for filling in many of the holes and conceptual shortcomings that I faced as a result of my previous methodologies.
All that being said, there are a couple things preventing me from giving this a 5/5. While complaining about the difficulty of vocabulary being used in a book may come off as a bit dumb, this book felt a bit verbose at times and included words that I felt made it unnecessarily difficult to understand. For example, are words like 'vociferously,' 'ameliorate,' or 'parochial' really necessary in a book about programming concepts? Additionally, there were a couple instances where Metz utilized some questionable syntax that she herself admitted is generally frowned upon. In her defense, this is a book that's intended to be about theory, and there are plenty of other resources if syntax is your primary focus.
Overall, I'd give this book a solid 8/10. In addition to strengthening your knowledge of OOP, you can expect to come out of this book with a deeper understanding of the English language as well.
June 23, 2019
First two-thirds of book seems useful and relevant to most programmers. Having a great test suite that you can lean on while refactoring is essential to slowly evolving your code. The care taken to explicitly edit one line at a time is an important one, particularly for a real-world, larger problem.
The latter third seemed less relevant for functional programmers (FP) and in particular Clojure users. With FP, you get a lot of the simplicity and performance since most everything is a pure function. Additionally, with Clojure's built-in persistent, immutable data structures, garbage collection is very efficient and object instantiation and memory allocation are not relevant. There doesn't need to be a tradeoff of understanding different objects passing messages and performance with mutable state.
I think the Primative Obsession code smell isn't a bad tradeoff since you don't have the indirection of different objects/instances which are introduced by the Extract Class refactoring pattern. This may break the Law of Demeter, but you get the benefit of a huge set of functions that operate on a few useful primative data strutures.
The latter third seemed less relevant for functional programmers (FP) and in particular Clojure users. With FP, you get a lot of the simplicity and performance since most everything is a pure function. Additionally, with Clojure's built-in persistent, immutable data structures, garbage collection is very efficient and object instantiation and memory allocation are not relevant. There doesn't need to be a tradeoff of understanding different objects passing messages and performance with mutable state.
I think the Primative Obsession code smell isn't a bad tradeoff since you don't have the indirection of different objects/instances which are introduced by the Extract Class refactoring pattern. This may break the Law of Demeter, but you get the benefit of a huge set of functions that operate on a few useful primative data strutures.
May 27, 2021
This is a book about Object-Oriented concepts, or should I say processes? It presents the reader a series of doctrines to follow which will improve the quality of the code.
The book begins by requesting the reader to write code which will produce the lyrics to the 99 Bottles of Beer song. How often do we get this? It then guides the reader on evaluating its own code. The book also presents four different solutions to its own challenge and uses them, by a series of refactoring, to present the topics of the book.
The book can be as practical as the reader wants it to be; either by passively reading the authors' approach to solve this problem, or; following along the book and apply those changes to the code directly.
I think this extract from the book makes a good td;dr summary: "Strive for simplicity. Don't abstract too soon. Focus on smells. Concentrate on difference. Take small steps. follow the Flocking Rules. Refactor under green. Fix the easy problems first. Work horizontally. Seek stable leading points. Be disciplined. Don't chase the shiny thing."
I read the Ruby version of the book and I think it's worth re-reading it in the Javascript version. Mostly because I use both languages. The concepts in this book are language agnostic and can be used on any object oriented programming language. One can take the exercise a little bit further and use it with some other OO language.
The book begins by requesting the reader to write code which will produce the lyrics to the 99 Bottles of Beer song. How often do we get this? It then guides the reader on evaluating its own code. The book also presents four different solutions to its own challenge and uses them, by a series of refactoring, to present the topics of the book.
The book can be as practical as the reader wants it to be; either by passively reading the authors' approach to solve this problem, or; following along the book and apply those changes to the code directly.
I think this extract from the book makes a good td;dr summary: "Strive for simplicity. Don't abstract too soon. Focus on smells. Concentrate on difference. Take small steps. follow the Flocking Rules. Refactor under green. Fix the easy problems first. Work horizontally. Seek stable leading points. Be disciplined. Don't chase the shiny thing."
I read the Ruby version of the book and I think it's worth re-reading it in the Javascript version. Mostly because I use both languages. The concepts in this book are language agnostic and can be used on any object oriented programming language. One can take the exercise a little bit further and use it with some other OO language.
July 22, 2022
This is an excellent book about Object Oriented programming with Ruby, Test Driven Development (TDD), and refactoring code. You should have some familiarity with Ruby to begin with so that you can actively take part in the exercises as it does start with asking you to write some code to produce a string consisting of the famous 99 Bottles of Beer On the Wall song. From there it introduces Test Driven Development, the practice of writing tests which you then craft a program to pass, using the most simple and minimal solution for each test. The book includes lots of hand-holding and is very well proofread so you can trust the text. It features a lot of content about what makes a good computer program and introduces different theories about that which it then puts into practice, again, using the Ruby programming language. This isn’t an introduction to Ruby but it is an introduction to thinking about what makes a good computer program and it very nicely straddles the divide between theory and practice - giving you enough of both to learn to code while learning how to think about computer programming in a way that will make you a better programmer.
January 11, 2025
I bought this book 6 years ago and made a terrible mistake of delaying the reading until now. It is truly a hidden gem!
The author begins by offering you to write a simple program in Ruby to meet a requirement of produces the 99 Bottles song. You're tasked to pass a suite of unit tests. No prior knowledge of Ruby is required. Upon completing the code challenge, you get to compare your solution to a set of common approaches. Using a simple framework each approach gets evaluated. I was happy to find out that my solution was close to the one author considered best. So at this point I thought, what else? And then a surprise change request dropped.
This is where the magic happens. The book guides you through the process of refactoring your code in order to meet the new requirement. In the spirit of Kent Beck, you make the change easy (warning: this can be hard), then make the easy change. Step by step you identify code smells and remove them under green tests. Gradually your solution becomes more open to the new requirement. Eventually the refactoring process is complete. In the spirit of TDD, you write a new test and using two lines of code solve the change request.
The author begins by offering you to write a simple program in Ruby to meet a requirement of produces the 99 Bottles song. You're tasked to pass a suite of unit tests. No prior knowledge of Ruby is required. Upon completing the code challenge, you get to compare your solution to a set of common approaches. Using a simple framework each approach gets evaluated. I was happy to find out that my solution was close to the one author considered best. So at this point I thought, what else? And then a surprise change request dropped.
This is where the magic happens. The book guides you through the process of refactoring your code in order to meet the new requirement. In the spirit of Kent Beck, you make the change easy (warning: this can be hard), then make the easy change. Step by step you identify code smells and remove them under green tests. Gradually your solution becomes more open to the new requirement. Eventually the refactoring process is complete. In the spirit of TDD, you write a new test and using two lines of code solve the change request.
February 21, 2023
Really enjoyed the beginning - was sure that I'll give 5 stars and eagerly recommend it to colleagues.
However, as the book went, at points it felt more theoretical than practical. Slightly simplified, yet still relatively extreme emphasis on TDD which I'm yet to see in the wild. The repetition across the chapters kept distracting more than adding value.
Despite all that, I'd still recommend the book to people. There are some great practical principles that can be transferred across any programming language (e.g. read about Ruby yet my primary focus is Java). There are patterns and lines of thought that can be useful for many developers.
Even at a more advanced professionals, it's still worthwhile occassionally re-evaluating whether I am writing code that is clear, extendable and maintainable. Can more junior people still follow the intent of the written code?
However, as the book went, at points it felt more theoretical than practical. Slightly simplified, yet still relatively extreme emphasis on TDD which I'm yet to see in the wild. The repetition across the chapters kept distracting more than adding value.
Despite all that, I'd still recommend the book to people. There are some great practical principles that can be transferred across any programming language (e.g. read about Ruby yet my primary focus is Java). There are patterns and lines of thought that can be useful for many developers.
Even at a more advanced professionals, it's still worthwhile occassionally re-evaluating whether I am writing code that is clear, extendable and maintainable. Can more junior people still follow the intent of the written code?
May 30, 2024
Excellent book on the way to develop OOP software. A very well paced and thoughtful journey through a series of refactoring moments. As the author of data-oriented design, there are many times where I winced at the implied performance problems introduces by the approach, but I can't fault the treatment of the subject. Very nicely laid out and very clear procedure.
The main benefit you will come away with is a mechanical process to reveal the places where you should be injecting dependencies, how to elicit them and verify them through tests and refactoring steps.
The value proposition is that these decouplings will lead to easier to maintain code. Whether they do will be determined by reality, and that will be specific to your problem and the revelations in your domain. The process does make OO code easier to test, so at least you will be making safer refactor steps.
The main benefit you will come away with is a mechanical process to reveal the places where you should be injecting dependencies, how to elicit them and verify them through tests and refactoring steps.
The value proposition is that these decouplings will lead to easier to maintain code. Whether they do will be determined by reality, and that will be specific to your problem and the revelations in your domain. The process does make OO code easier to test, so at least you will be making safer refactor steps.
July 1, 2021
Did this book again as a book club for work. Maybe the 2nd edition has been significantly updated or I didn't actually finish the whole thing last time, but either way, it's still a wonderful book for a software developer that's had a few years under their belt. Sandi and co. fall very much towards the mockist/unit-testing end of the spectrum, but even if one's personal preference leans the other direction, 99 Bottles is still very much work reading to see how interleaved the mockist style is with code design.
It's one of the few actually practical books to read on programming (especially wrt. refactoring and design) as a craft, and I'd recommend it without reservation for pretty much any type of developer, regardless of language.
It's one of the few actually practical books to read on programming (especially wrt. refactoring and design) as a craft, and I'd recommend it without reservation for pretty much any type of developer, regardless of language.
June 18, 2017
The book describes a program that prints the 99 bottles song, and more importantly the detailed steps of refactoring the program. The task seems to be pretty simple, but in fact the average, basic code for the solution is far from ideal, and the book explains how to improve it. From this point of view, it's a perfect fit. I'm impressed by the detailed explanations of the refactoring process.
It's also interesting to compare it with this article: , which describes several implementations of the Fizz-Buzz program with functional programming.
It's also interesting to compare it with this article: , which describes several implementations of the Fizz-Buzz program with functional programming.
February 4, 2018
This book has written for a pretty wide audience (TBH I think that this audience is too wide). I'm not sure that it's worth reading for experienced software engineers, there are no things that will blow your mind, but I'll definitely recommend this book for junior/middle-level devs.
Please, guys, don't ignore practice! Try to write your own solution of 99 bottles and then see, how it differs from Sandi's solution. Even better if you'll be repeating refactoring step by step, as shown in the book.
Please, guys, don't ignore practice! Try to write your own solution of 99 bottles and then see, how it differs from Sandi's solution. Even better if you'll be repeating refactoring step by step, as shown in the book.
March 18, 2018
Sandi Metz's prior book sets the bar very high, so I had higher expectations for this one, but it is still absolutely worth reading. It focuses on different strategies and tradeoffs when implementing a ruby program that spits out 99 Bottles of Beer song. It covers topics like naming, extendability, developer speed, changing requirements, abstraction etc..
January 28, 2019
Without a doubt this is one of the best programming books that I've read. It's a masterclass in refactoring and object-oriented design. The reason it's so effective is that it focuses on solving one problem over the course of the entire book, improving the solution's design progressively each chapter. The authors have an uncanny sense of the common stumbling blocks that programmers encounter when designing systems, and they provide very detailed, prescriptive techniques that every programmer will find useful.
November 2, 2020
This book is my favorite of all the books on programming that I've read at the moment. It has tremendous concentration of useful advices and wisdom. I like the way it is structured and the detailed explanations of thoughts that stay behind each decision that the author takes while it studies the "99 bottles" song problem. Now I have understanding of why OOP matters and how properly applied SOLID (not only) principles lead to beautifully designed code that is easy to read and understand.
Thank you Sandi Metz for this profound work! I wish I would read it earlier in my career.
Thank you Sandi Metz for this profound work! I wish I would read it earlier in my career.
June 25, 2021
Great foundational thoughts towards OOP. Sandi Metz is a great teacher and even has small tid bits throughout each chapter that enlightened my thoughts. The only reasons I am giving the book four stars is because the book doesn't flow well towards the end. You feel like you're drifting off of a conversation that reached its endpoint, but only for the last few chapters. Additionally, while she nails Liskov's substitution principle and even uses a few other different principles, I found the book needing to use more in its teaching.
The book is 100% worth the read, especially as a team.
The book is 100% worth the read, especially as a team.
January 31, 2018
This book is definitely among the top 3 best books about programming of all time. Sendi Metz and Katrina Owen lead you to the solution of a well know problem. Not too complex and not too shallow, just at the right level that allow them to exemplify how to make decisions about code design at every step of the way, all guided by tests. Can't recommend this enough, I will most certainly read multiple times.
December 10, 2019
A wonderful book that goes step by step in how to think in the world of OOP when you are in a dynamic language. Provides references to books which i wished would first explain the points together and then expand from them instead of inter-weaving them in. Overall however, its a must read for ruby-ist and people interested in OOP to provide a foundation of how to not only refactor code, but refactor code in an OOP mindset.
Displaying 1 - 30 of 75 reviews
Can't find what you're looking for?
Get help and learn more about the design.