dorinlazar's review against another edition
3.0
An essential book at the time, but now more or less common knowledge. The approach is less interactive than expected, and the book becomes quite useless after the introductory chapters.
This is an essential book for any developer, but I tend to believe that the techniques for refactoring presented here can be presented in a more intuitive manner. An accent on code smells would've been preferable. Most of the solutions are obvious and the cross referencing becomes tiresome after a while.
This is an essential book for any developer, but I tend to believe that the techniques for refactoring presented here can be presented in a more intuitive manner. An accent on code smells would've been preferable. Most of the solutions are obvious and the cross referencing becomes tiresome after a while.
omarelkhatib's review against another edition
4.0
I have read the 2nd version,
It's a classical book that you must own,
and keep it as reference.
Many common sense refactoring if you have been programming for a while.
It's a classical book that you must own,
and keep it as reference.
Many common sense refactoring if you have been programming for a while.
dreamingblackcat's review against another edition
5.0
I think I'll probably mark this book is currently-reading throughout my career. Because I am referencing it every now and then even today.
When I first read it, I dropped it after a few chapters. I was a naive junior programmer and the book was a bit mundane and boring. I am not getting anything special out of it.
Years later, when I get to work on a legacy code base with every code smell in the book manifesting here and there, I start to appreciate this book.
Each of the techniques in the book on their own doesn't seem all that useful. But the trick is when you master how to appropriately combine them to get your code into better shape gradually.
I think it is definitely a must-read for programmers who want to get good at their craft.
When I first read it, I dropped it after a few chapters. I was a naive junior programmer and the book was a bit mundane and boring. I am not getting anything special out of it.
Years later, when I get to work on a legacy code base with every code smell in the book manifesting here and there, I start to appreciate this book.
Each of the techniques in the book on their own doesn't seem all that useful. But the trick is when you master how to appropriately combine them to get your code into better shape gradually.
I think it is definitely a must-read for programmers who want to get good at their craft.
flerkamary's review against another edition
4.0
I think it's really great book but developer should have enough experience to use information from it.
xii_emisario's review against another edition
informative
slow-paced
3.75
Siento que leí este libro muy tarde en mi carrera, creo que el momento prefecto hubiera sido después de unos dos o tres años de experiencia en desarrollo de software.
Si usted revisa código al aprobar por ejemplo un pull request, esta también será una herramienta muy útil.
Si usted revisa código al aprobar por ejemplo un pull request, esta también será una herramienta muy útil.
kwugirl's review against another edition
4.0
Finally finished this, long after the book club for it was over! This is a classic, which means there are both really good pieces of wisdom in here as well as concerns that don't need to be worried about so much anymore with more modern tools and text editors. The majority of the book is kind of a reference of refactoring "recipes" with checklists to go through to make sure you haven't missed something--time will tell if I end up using that reference portion. The descriptions and motivations for performing said refactorings was all good though, since it went through both when you would or wouldn't use something. The main thing I learned was that your code should pretty much constantly be in a state of needing refactoring, since you shouldn't refactor until you know what the next thing you're doing is and it should be the first step.
firat's review against another edition
5.0
This is by far the most concrete and example driven book I've read on how to write clean code. And I want to say that this is currently the number one book I would recommend to every software development professional.
In summary there are 2 ways to write clean code:
1- Use every single brain cell you have before writing your code for the best possible design
2- Refactor along as the code matures and requirements change
I have almost always seen that is much safer to go with the second option.
The book talks about refactorings we do everyday, only gives them proper names and uses them as nouns. So instead of telling us to 'extract' the method Fowler uses the phrase "Use 'Extract Method'". This actually helps you remember the methods by their titles. This gets useful when he explains more complex refactorings. He explains the more complex refactorings by using simpler refactorings(which actually feels like re-using code, but now it is a refactoring method).
The only complaint I have with this book is the examples of mirrored refactorings. The examples did not justify them well. The codes in the examples were exactly the same but only the before and after had switched places. I would have preferred examples that made sense to apply the changes instead of a lame excuse that tells me that I might need to do 'this refactoring' in some situations. But luckily this was only a concern in a few chapters. Most of the refactorings Fowler applied on the book just made sense and made the code better.
Thank you Martin Fowler Sir for writing this book. I hope we can one day meet each other in real life.
In summary there are 2 ways to write clean code:
1- Use every single brain cell you have before writing your code for the best possible design
2- Refactor along as the code matures and requirements change
I have almost always seen that is much safer to go with the second option.
The book talks about refactorings we do everyday, only gives them proper names and uses them as nouns. So instead of telling us to 'extract' the method Fowler uses the phrase "Use 'Extract Method'". This actually helps you remember the methods by their titles. This gets useful when he explains more complex refactorings. He explains the more complex refactorings by using simpler refactorings(which actually feels like re-using code, but now it is a refactoring method).
The only complaint I have with this book is the examples of mirrored refactorings. The examples did not justify them well. The codes in the examples were exactly the same but only the before and after had switched places. I would have preferred examples that made sense to apply the changes instead of a lame excuse that tells me that I might need to do 'this refactoring' in some situations. But luckily this was only a concern in a few chapters. Most of the refactorings Fowler applied on the book just made sense and made the code better.
Thank you Martin Fowler Sir for writing this book. I hope we can one day meet each other in real life.
miguel_ocana's review against another edition
4.0
Además de un 'Must Read' es un libro al que hay que volver cada cierto tiempo.
Los consejos y puntos claves están escondidos entre la colección de refactors que va explicando.
De vez en cuando también incluye alguna perla de humor inglés.
Algunos Refactors pueden parecer muy simples, pero son necesarios ya que va apoyándose en los simples para ir construyendo los más grandes.
También hay mucha insistencia en las mecánicas y su importancia, en principio puedes pasar de forma superficial, pero el libro esconde lo necesario para realizar los refactors sin perder en ningún momento la capacidad de compilar y pasar todos los tests en verde.
Es curioso ver como cada refactor tiene su refactor contrario, como todo en informática, no existe una única forma correcta de hacer las cosas, y dependiendo mucho de la situación y el problema encontrado se recomienda un cambio o el contrario.
El libro tecnológicamente está desactualizado, pero su mensaje es asombrosamente vigente.
Le he quitado la quinta estrella porque se centra en los refactors sin entrar en cómo tejer la red de tests unitarios que se debe tener para empezar a hacerlos.
Los consejos y puntos claves están escondidos entre la colección de refactors que va explicando.
De vez en cuando también incluye alguna perla de humor inglés.
Algunos Refactors pueden parecer muy simples, pero son necesarios ya que va apoyándose en los simples para ir construyendo los más grandes.
También hay mucha insistencia en las mecánicas y su importancia, en principio puedes pasar de forma superficial, pero el libro esconde lo necesario para realizar los refactors sin perder en ningún momento la capacidad de compilar y pasar todos los tests en verde.
Es curioso ver como cada refactor tiene su refactor contrario, como todo en informática, no existe una única forma correcta de hacer las cosas, y dependiendo mucho de la situación y el problema encontrado se recomienda un cambio o el contrario.
El libro tecnológicamente está desactualizado, pero su mensaje es asombrosamente vigente.
Le he quitado la quinta estrella porque se centra en los refactors sin entrar en cómo tejer la red de tests unitarios que se debe tener para empezar a hacerlos.