57 Rezensionen
5 Sterne:
4 Sterne:
3 Sterne:
2 Sterne:    (0)
1 Sterne:
Durchschnittliche Kundenbewertung
Sagen Sie Ihre Meinung zu diesem Artikel
Eigene Rezension erstellen

Die hilfreichste positive Rezension
Die hilfreichste kritische Rezension

12 von 12 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Standardwerk + Pflichtlektüre
Dieses Buch sollte bei jedem (angehenden) Software-Entwickler im Bücher-Regal stehen ! Bevor ich dieses Buch gelesen habe, wusste ich ehrlich gesagt nicht wirklich was ich alles unter dem großen Begriff "Refactoring" verstehen soll.
Es wäre auch falsch und naiv zu behaupten das ich nach diesem einen Buch die Kunst des Refactorings...
Veröffentlicht am 31. März 2006 von Klaus M.

3 von 3 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Good addition
Matin surely presents a good strategy which is easily proved in the book. However I do not think it is a big enough issue to justify the whole book. He filled the content with many basics of object oriented and good programming practice. While many are not familiar with patterns and these techniques are not used as much as they should, I expect better material from...
Am 28. Oktober 1999 veröffentlicht

‹ Zurück | 1 2 36 | Weiter ›
Hilfreichste Bewertungen zuerst | Neueste Bewertungen zuerst

4 von 5 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Making tired old code better, 17. Mai 2000
The basic thesis of this book is that, for various reasons, real programs are poorly designed. They get that way for a variety of reasons. Initially well designed, extending the program may lead to software decay. Huge methods may result from unanticipated complexity. Refactoring, according to Fowler, is a function preserving transformation of a program. The transformations are reversible, so the intention is to improve the program in some way.
Fowler suggests refactoring a program to simplify the addition of new functionality. The program should also be refactored to make it easier for human readers to understand at the same time.
He also insists that each step is small and preserves functionality, and on frequent unit testing with a comprehensive test suite.
Half of the book consists of a catalogue of refactorings. He gives each refactoring a memorable name, such as "Replace Type Code with Subclasses". He illustrates the design transformation with a pair of UML class diagrams, and has a standard set of sections: Motivation, Mechanics and Example.
The Motivation is a prose section that describes and justifies the refactoring, showing the relationship to other refactorings.
The Mechanics is a sequence of steps needed to carry out the refactoring, shown as a list of bullet points He expands on some points.
The Example is where the value of this book lies. Fowler takes a fragment of Java code, and takes us step by step through the refactoring. The code is small enough that he can show it all each step of the way without overwhelming us, but is large enough to be realistic.
The code is clear enough for non-Java programmers to follow. He explains his code well enough for the book to function as a Java tutorial where the meaning of the code is not obvious. One or two of the refactorings are specific to the Java object model, and do not apply to other languages. Other languages would benefit from similar treatment, but there are very few language-specific refactorings.
The book is very much of the Design Patterns movement, with frequent references to patterns. The aim of a factoring may be to achieve a particular pattern, or it may take advantage of a particular pattern. The book can be used as a tutorial on Design Patterns.
I have a small number of complaints. Fowler advocates the use of refactoring while studying code for a code review. One needs to be very sensitive to the feelings of the programmer here, especially if he or she is a novice. The reviewer should read the code with refactoring in mind, and possible refactorings recommended, but it is for the programmer to make the changes.
Reading this book has inspired me to refactor some of my own code. My mistakes underlined the need to take small steps, and to test frequently. I spent a day building a useful Delphi testing framework from the description Fowler gives of the JUnit testing framework. The one category of code that does not seem to lend itself to this approach is some highly coupled parsing code. While I can extract small blocks of code, they remain tightly coupled with each other, and it is hard to give them meaningful names. The answer here may be to use the top down approach of recursive descent, rather than the bottom up approach of refactoring. Perhaps recursive descent can guide refactoring. Refactoring is largely a local approach. One can almost say a pinhole approach. Sometimes a global view is needed.
In summary, I would say that this very good book would be of use to Java programmers who have some understanding and much bafflement. It is very good for us older dogs who have become a little jaded and need some new ideas and motivation.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Vital for every programmer, of great practical value., 8. Juni 2000
Dave O'Hearn (Boston, MA United States) - Alle meine Rezensionen ansehen
Unlike the AntiPatterns book, this one is valuable to every programmer, not just team leaders and academics. Refactoring is for everyone; I was doing it long before I knew what it was. Simply put, it is cleaning up the design before you add a new feature, so that the new feature will work with the design rather than fight it. The methods outlined in this book go beyond common sense, giving step-by-step guides to help refactoring be done safely and formally.
The text is also of great value to programemrs who learned the procedural style and still fealing it lingering in their object oriented designs. I have only owned it for two days and it has already contributed significantly to my knowledge of good object oriented design and implementation. It is one of the few books per year that I can afford to purchase and keep as a reference.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

16 von 21 Kunden fanden die folgende Rezension hilfreich
1.0 von 5 Sternen Good Information But Extremely Poor Delivery, 15. März 2000
This book contains some good information on how to improve yourexisting code without rewriting it entirely which is a nice departurefrom the norm of most of these UML-type books which advocate totally changing the way you design and build software. Not that the Unified method of designing and building is bad, its just that its hard to change the way this is done in an organization when you're not in charge of the organization. Mr. Fowler has put forth a mechanism for improving the design of existing code while adding functionality to it. And the information, once culled from the surrounding text, is extremely useful. It's not paradigm shift. And it's not a companion to Design Patterns - Fowler mentions the Design Patterns book throughout his text but this book is certainly not written for the same audience. Fowler never once gives an example where he converts bad code into good by utilizing a pattern from the Gang of Four's book. The book is useful for ANY object-oriented language even though he uses Java in his examples the principles map easily to C++ and SmallTalk. Almost all of the techniques are common sense and yet he spends the bulk of this book explaining in simple terms how to perform them. For each "refactoring" he capably provided a two or three sentence overview of the process, and a code fragment or class diagram exemplifying the technique. These summaries and figures are excellent. But his tone becomes condescending as he painfully explains the process of performing the code improvement. For instance, Extract Method, the first technique in the book, is succinctly described with: "[If] You have a code fragment that can be grouped together...[then] Turn the fragment into a method whose name explains the purpose of the method." Pretty simple and probably not quite enough to totally understand what he is talking about. But then he has a wonderful little code fragment that illustrates it perfectly. This requires about half of one page. But he spends four and a half more explaining how to perform this simple cut-and-paste. 270 Pages of this 418 page book are spent describing 72 techniques in this kind of excruciating detail. Eight very useful pages are spent describing the bad "smells" in your code that lead to these "refactactorings". Another 110 pages is spent telling you how to justify the work to your boss, encouraging you to do it whether or not your boss approves, advocating a "test-small-change-test" paired programming technique characteristic of Extreme Programming. The final 30 pages are written by the other contributors. Altogether, I think this book should be "refactored" into a 100 to 150 page soft-cover manual reminiscent of Scott Meyers' Effective C++ books. If you're looking for Design Patterns: Part 2 this isn't it! END
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

5.0 von 5 Sternen Incremental changes can and do make a difference, 20. Februar 2000
Charles Ashbacher (Marion, Iowa United States) - Alle meine Rezensionen ansehen
The majority of books describing the development process deal with the design phase. Clearly, this is important, but the latest information is that eighty percent of development time is now spent in the area known as software maintenance. Information concerning how to perform this vital function correctly has been conspicuously deficient. After the publication of this book, that oversight is substantially corrected.
Refactoring is defined as the modification of pre-existing code to improve the performance, and does not directly involve the modification of code to add additional functionality. That aside, improving the efficiency of the code is a valuable goal that is now more attainable.
Given a system that does work, making changes to improve performance is often not a high priority. In the high speed world of software development, making a change that adds only percentage points of improvement in one area does not raise eyebrows, it tends to create frowns. However, like so many other things, this is a very short-sighted view. In my mind, the most significant lesson of the Y2K event is that code tends to live a long time, despite dramatic changes in the hardware. Those simple changes that we do now may not save much time per execution, but iterate that over decades and the return on investment is quite high.
The most significant advantage of the improvements described in this book is that almost all of them can be implemented fairly quickly and can be verified locally, without global recompiles and exhaustive retesting. Therefore, the management decisions that need to be made to carry them out entail much less risk. It is also much easier to allocate resources if it is known with a high degree of certainty that the modification will be completed in a matter of hours rather than days or weeks. This is also consistent with the body of evidence that is overwhelming in favor of a software development cycle with small iterations that can be quickly completed.
No one single refactoring operation listed here will change your application from a tortoise to a hare. However, each one will add a bit more bounce to her step, and if you perform enough of them, you will have either a very fast tortoise or a slow hare. This is a book that should be required reading in all sections that perform software maintenance. If I were in a position of maintaining software, I would create a checklist of refactorings and simply step through that list looking for places to make the changes. There is no doubt that this is one of the best books of the year.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

4 von 5 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Should be titled "Refactoring for Java Programmers", 13. Dezember 1999
As a C++ programmer I found many of the examples strongly geared to the specifics of the Java language (with which I have little familiarity). I was hoping for a more substantive generic OOP book. Many of the examples are OOP common sense and the book comes off as more of a beginners book for Java programming than one aimed at the audience of "Design Patterns" (an excellent book).
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

5.0 von 5 Sternen Very valuable contribution towards Programming folklore., 22. Juli 1999
First one small complaint about this book: It introduces the notion of "bad smells in code" which are nothing but "Anti-patterns". Why introduce another new term? The notion of "Antipatterns" was introduced by another book with that title. That book too handled some of the issues of "Refactoring" although at different level and hence should have atleast been mentioned in the bibilography.
Interesting thing is that the "Catalog of Refactoring" in this book is in inverse format of the "Catalog of Anti-Patterns". That is not a bad thing though.
Many thanks to all these authors (like the GoF and Fowler-Beck-gang) who giving the OO programming world a higher level vocabulary, by giving names and cataloging simple types of changes that you make to your code to rejuvenate it. That is a very important contribution towards documenting valuable programming folklore.
The book is pretty focused. The authors talk of little Refactoring. And don't digress into suggesting ways to handle Architectural or Infrastructural Refactorings (like say moving from Monoliths to N-Tiers). That makes it a fun yet valuable read.
This are my own views not my employers
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

5.0 von 5 Sternen Must-have for every Senior Java Developer, 19. Juni 2000
Von Ein Kunde
This book deals with a real-life software problem: maintenance of existing code. 90% of a developers work time are spent to maintenance programming and not to developing new designs and classes. This book guides how to take ownership of existing code which to my experience is a horror to most average-experienced software developers. The design patterns presented show what makes code a maintenance nightmare and how to rework such code. Thus it not only teaches hot to rescue existing code but also prevents oneself from writing code which is prone to be thrown away one day. Accompanied with "Java Idioms and Performance Guide" this book is the third one which I would recommend to a Java beginner after having read one entry Java book. Most experienced developers will have much "deja-vue" situations while reading; it's the same as with design patterns books. Before I read the book I sometimes blamed me for working on others persons code instead of using it "as-is" - now I know I'm not alone and some talented seniors do it the same way. In fact I saw many long-term projects die because of an increasing loss of architecture and constantly decreasing code quality. Refactoring could have rescued at least some of these.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

5.0 von 5 Sternen Not just for Java, 28. Februar 2000
Bevan Arps (Wellington, New Zealand) - Alle meine Rezensionen ansehen
This is a book that will change the way you view code - as you are writing it and when you are maintaining it.
While the examples are written in Java (and a couple of the refactorings seem to be Java-isms) this is a book that should change the way you look at your code - no matter what language you use.
If you look at any code at all - if you are author, maintain or review code in any language - you should get this book, read it, and leave it on your desk.
Like many fundamentally good ideas, refactoring seems so simple that one wonders why we didn't think of it before. Fact is, refactoring has been happening for years (decades) but Fowler is one of the first to make this process accessible.
If you are a very experienced developer, this book will help you put some of your own practice into words, to explain it to other developers on your team. You will probably learn a few new wrinkles as well.
If you are a less experienced developer, this book can help you to become better at your craft. You'll find out some of the "tricks of the trade" used by the best developers (those who produce the most reliable, most maintainable code).
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

6 von 8 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Ich vermisse das große Bild, 15. Oktober 2002
Verifizierter Kauf(Was ist das?)
Wenn man dieses Buch durchgearbeitet hat, verändert sich automatisch die Art und Weise wie man programmiert und wie man geschriebenen Code bearbeitet. Man traut sich an den Code heran und bricht alte Strukturen auf um diese zu verbessern.
Man denkt sich nicht mehr: "Ach, dass sieht zwar schlecht aus aber es funktioniert. Irgendwie bekomme ich das neue Feature auch so da rein."
Nun geht man hin und verbessert Schritt für Schritt das Design bis es leicht wird das Neue einzubringen.
Auf jeden Fall eine geniale Möglichkeit seine Produktivität zu steigern.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

5.0 von 5 Sternen At least as important as Design Patterns. Buy it now., 20. Juli 1999
Michael D. Hill "GeePawHill" (Charlottesville, Va) - Alle meine Rezensionen ansehen
It's a rare book that causes the reader to say: "This changes *everything*." The Design Patterns book is one such, Refactoring is another.
The introductory chapters establish a clear theoretical and practical basis for the catalog of refactorings that make up the larger part of the text. Many of the examples are trivial, but then, many of the refactorings occur in simple situations. The more complex refactorings are usually accompanied by detailed example code. The mechanics section in each refactoring is an outstanding tool, and I expect to use it quite frequently.
I have followed the 'extreme programming' (XP) movement for some time, and I'm an ardent fan, as is, so I gather, Fowler himself. But don't be fooled by this: the book is not just for the XP crowd. All programmers who use Java (or have used more than one other oo language), will find this book a huge resource. I have a library that I recommend to journey-folk who aspire to mastery. Refactoring is certainly the newest addition. I think this book will be an instant classic.
I cannot say enough. Why not buy it now?
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

‹ Zurück | 1 2 36 | Weiter ›
Hilfreichste Bewertungen zuerst | Neueste Bewertungen zuerst

Dieses Produkt

Nur in den Rezensionen zu diesem Produkt suchen