You need to sign in or sign up before continuing.
Take a photo of a barcode or cover
firat 's review for:
Refactoring: Improving the Design of Existing Code
by Martin Fowler
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.