Refactoring: Improving the Design of Existing Code

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.

Great book. I like this older revision as the newer ones switched to JavaScript which I don’t use. Great intro to refactoring and a great reference book on refactoring.

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.

This book is replete with advanced knowledge of the situational logic of refactoring code in procedural and object oriented languages ... The point of view is that of a software engineer inclined to perfectionism ... Many typical kinds of bad code from a module or a function or a method or a class are outlined in Chapter 3 item by item 22 different situations are described and critiqued ... Much of the remainder of the book outlines what remedies the principal author and the other authors suggest as to how to refactor the code to meet this book's standards ...One doubt immediately comes to mind: what about the economics in industry of refactoring? Whilst I agree, say, that a car self parking system needs to be well nigh perfect in that this is the only way to assure safety for car drivers and nearby pedestrians, many an employer will say no just say no to refactoring exercises for perfection's sake! For example, many financial systems have the odd unimportant user interface bug that there's simply not the funds to get fixed.And every source code change involves risks: the risk that bugs are introduced; the risk that the unit and system testing will be inadequate; the risk of feature drift, the application semantics being misunderstood; and, the risk of loss of source code though related hardware failure. Source code control systems and people employed as change managers need to question whether the risk of some minor change should be countenanced, or rejected if too risky!It is possible that too many refactoring exercises might take a large system that works well and lead to it degenerating into an unholy mess, with added introduced bugs, the destruction of the original architect's vision, and changes that erode the system's integrity and purpose. This is a management problem. Quality code is not free. If a large system really needs extentive refactoring the real question is as to whether over the expected lifetime of the code it would be cheaper to refactor, or to throw the system away and start from scratch!It is overall more advisable to get the system right in the first place. A better design with a better architecture if put together for a hypothetical version 1 of a large system will reduce maintenance cost down the track ...Nevertheless an excellent book of practical advice on refactoring and code quality!An advanced reference work for third year university software engineering students, practising software engineers, and software engineering managers. Managers whose background is other than a career in programming would particularly benefit from this work.