Refactoring: Improving the Design of Exi Paperback

Refactoring: Improving the Design of Existing Code is one of those amazing books that every professional developer should have on their book shelf. The bulk of this book is a catalog of refactorings, but there is more to it as I will explain below.In case you aren't aware of what refactoring is, I'll give you Fowlers definition."Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure." For the most part this means cleaning up your existing - yet working - code. It involves anything from renaming a method to be more concise with the purpose of that method, to breaking up switch statements into a polymorphic structure. There are many different techniques used to refactor your code, which is what you learn in this book.Right off the bat Fowler throws you into a small sample application that is poorly designed. He then takes you through a few different refactoring techniques that improve the design of this simple application. Right from the start you see how effective refactoring can be. From there he goes into topics such as how to detect "bad smells" in code. This chapter is particularly informative and entertaining. You also learn a little bit about testing. After the introductory chapters you begin to dig into a deep catalog of refactorings. Each one is named. Like design patterns - naming the refactoring and building a vocabulary really helps in communicating thoughts and ideas.The catalog of refactorings is extremely useful. They are structured so that each refactoring has a name, a motivation, the mechanics and a simple example. This is very effective. As I said earlier, the name is useful because it helps build your programming vocabulary and it helps in communicating thoughts and ideas. The motivation explains why the refactoring should be done and when it should/shouldn't be used. The mechanics provide a step-by-step description of how to carry out the refactoring and the example shows a small example of the refactoring in use. All examples are written in Java 1.1.Although the examples are written in Java the book is still very good for any developer. Developers that have never written a line of code in Java, C++, C#, or anything similar may have a little bit of a tougher time working through this book. Luckily most examples are very small and simple so even if you fall into this category you shouldn't have too much of a learning curve. Some of the code is a bit outdated and can be done a bit better now-a-days but what do you expect? This book was written 8+ years ago! Times have changed. The ideas are still very relevant though, which is what makes this book so timeless.Martin Fowler books are always a joy to read. His writing style is humorous, yet often very blunt and to the point. Just like UML Distilled, he is able to communicate a lot of ideas into a very short amount of space - the book is a bit dense in other words, which is very good in my opinion. Martin Fowler does not beat around the bush and he has very strong opinions on certain topics. Unlike a lot of books you read, he actually writes with personality. I have a hard time putting his books down. Here is an example of the type of verbiage he uses...On how comments can be a "bad smell":"Don't worry; we aren't saying that people shouldn't write comments. In our olfactory analogy, comments aren't a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant." - Martin Fowler. Here he is talking about how people use comments to hide bad code, or "bad smells".I highly recommend this book. If you are a professional developer or plan on becoming one then click the "Buy Now" button without second thought. This is one of those rare books worth its weight in gold - I would spend $100.00 on a book like this if I had to.

The authors need to be congratulated and thanked for their humorous and engaging presentation of what could have been a long dry and dreary list of dos and don'ts.I just started reading this book and I was wondering if it is going to be too dry and difficult to read. Instead, I have been pleasantly surprised on how entertaining - along with being informative, educative and thorough - this book is.There are several interesting anecdotes - the narration of which is aimed at underscoring what is important and where we should focus our efforts on. The lead author engages in quite a bit of self deprecating humor while narrating these stories - while clearly having written this book - he is an authority on the topic and all the techniques being described. The point of the humor - as I understand is to help us adopt good practices and good coding habits.In addition to these anecdotes, the book is littered with witty and funny prose in order to drive home important points. Here is a sample from the text where the authors tell us why they included "Comments" as one of the code smells:"Don’t worry, we aren’t saying that people shouldn’t write comments. In our olfactory analogy, comments aren’t a bad smell; indeed they are a sweet smell. The reason we mention comments here is that comments often are used as a deodorant."I can't remember having seen humor being applied so effectively in a text/reference book of this stature to make a point. And the point being made here is that comments often tend to describe code which is hard to understand and good code should be self descriptive and hence comments should not really be needed if the code was indeed self-descriptive. I am happy that such a writing style makes it hard for me to put the book down and to continue reading!

This book is a bit old. It is the first, or among the first, which addresses the refactoring issue. However, everything in it is relevant today.At the beginning and at the end you will find articles by various authors (Fowler, Beck, Opdyke, Roberts and Brant):* Refactoring , first example.* Principles of refactoring .* Bad smells in code .* Building Tests.* Toward a Catalog of Refactorings .* Big Refactorings .* Refactoring , Reuse , and Reality .* Refactoring Tools.* Putting It All Together.In the middle will find a great catalog of small transformations that define the steps to do the refactoring. This catalog, though simple is very important as explained in the first chapters.Fowler clearly explains why refactoring, some clues to identify the most important issues (code smells) to refactor in order to improves the design, and the catalog of transformations that are commonly used to solve each code smells.Dependending your experience and knowledge of software craftsmanship, you will surely perceive it more or less as a simple topic, but that makes it no less important.It is a fantastic book. It is one of the books that every software developer in the industry should read. The only reason I'm not giving 5 stars is that it is not a truly revealing book. The items inside are all very basic and simple. You should not expect anything astonishing and the first impression is that all of it is obvious, but it is explained in an exceptional way and the catalog created by Fowler is really great.

The book is in very good condition. The delivery was extremely fast and via courier.

Livro muito bom, indico para qualquer desenvolvedor ou pesquisador que trabalhe com refatoração.

I should have read this a few years ago. Ideally just after I'd first learned Java.Till I read this I'd always refactored on the basis of performance, reflecting a prior career in hard engineering. So if I used a block of code more than once then I extracted that block as a method. Or if I used a computed value more than once in a code unit then I used a temp variable to store that value and save repeated computation. Otherwise I usually left the code as it was.After reading the very lucid (and honestly written) first 3 chapters I will never be so simplistic again. Fowler advises refactoring even if only to improve readability of the code. But refactoring ought to also be done with object-oriented design advantages in mind, e.g. maintainability and extendability. So long lists of class attributes or method parameters are discouraged in favour of grouping in an array or agglomerates; interface differentiation preferred to sibling class creation and so on.Fowler explains how refactoring itself does not address performance issues - in fact the refactoring process may reduce performance a bit. Neither will refactoring eliminate performance drag due to bad system architecture: system design always remains the primary way to achieve performance. But refactoring does prepare code for final optimisation in that it breaks it into its sort of natural components which can then be analysed individually. Performance issues, like so many other effects, follow a Pareto distribution: 80-90% of the drag is attributable to 10-20% of the code components. So refactoring provides a means of getting the maximum gain in system speed with the minimum of code or algorithm changes - as well as the primary benefit of readable and reusable code.The organisation of this book is itself commendable. After easily read intro chapters, he has catalogued all minor refactorings in several subsequent chapters using UML diagrams as well as explanations. Major refactorings are presented after this. Then some actual case studies with commercial systems are covered, software tools for refactoring are discussed and a final summing-up chapter with last tips. Inside the front cover we have a convenient index of the refactorings. And inside the back cover we have an index of code smells (code items that just seem intuitively obtuse) opposite their recommended refactoring.Many previous reviewers of this book said this stuff is already in Gang Of Four or Josh Bloch's Effective Java. Some even opine that the book is puffed out and could use some refactoring itself. This is the just the kind of response you get from dumb people after they see a solution presented to them: it sublimely ignores the fact that those same people didn't even recognise the original problem - let alone its solution. I take my hat off to Fowler for this work. Despite its age and the primitive Java version used, the essence of this work still holds true nearly 20 years on. That alone makes it a software classic.

Some people say this book is not relevant anymore. To me, its obvious that it's completely relevant as of 2017. This book changed my attitude toward programming. I used to spend lots of time to design the software architecture and was too obsessed with my coding style. This approach caused me to become very unproductive and slow. Then I started reading this book and was noticed that my approach was wrong (read it to see why it is wrong to be obsessed with planning your software architecture before writing code). This book answers many of questions that I had but couldn't find the answers even on stackoverflow. The language of this book is funny and I loved the way author(s) talks with the reader. I highly recommend it especially for intermediate and advanced programmers.

Definitivamente muchos otros libros se inspiran en este libro para hablar de la refactorización. Sin mencionar que de este libro nació uno de los principios de los principios SOLID.