Kundenrezensionen


57 Rezensionen
5 Sterne:
 (47)
4 Sterne:
 (6)
3 Sterne:
 (3)
2 Sterne:    (0)
1 Sterne:
 (1)
 
 
 
 
 
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.

versus
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 26 | Weiter ›
Hilfreichste Bewertungen zuerst | Neueste Bewertungen zuerst

12 von 12 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Standardwerk + Pflichtlektüre, 31. März 2006
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 beherrschen würde, das macht der Autor Martin Fowler, sowie zahlreiche der "Gast"/Co-Autoren (v.a. Kent Beck) auch an einigen Stellen klar.
In diesem Buch werden wirklich zahlreiche Refactorings aus unterschiedlichen Bereichen behandelt, sei es nun wie man einen Konstruktor durch eine Factory-Methode ersetzt , eine Methode korrekt umbenennt oder Delegation durch Vererbung ersetzt etc. pp.
Der Aufbau der einzelnen Refactorings ist immer gleich:
Name - Zusammenfassung - Motivation - Vorgehensweise - Beispiel.
Es wird also geschildert wann man dieses Refactoring anwenden sollte, warum und v.a. auch wie. Bei den Beispielen handelt es sich meist um Java-Code, in wenigen Fällen werden auch nur UML Diagramme verwendet.
An manchen Stellen erkennt man zwar schon das das Buch nicht mehr das neuste ist, z.B. gefallen mir einige wenige Aspekte des Java-Codes nicht, aber das sollte kein Grund sein sich das Buch nicht zu kaufen.
Ich denke das es sogar hilfreich für Programmierer anderer Sprachen ist , auch wenn der Beispiel Code in Java ist, denn die Erklärungen sind allgemein gehalten.
Das Buch gefällt mir nicht zu letzt auch deswegen so gut, weil die Autoren auch die "Gefahren" ansprechen. Sie beschreiben Refactoring nicht als "Allheilmittel", sondern machen deutlich das man in kleinen Schritten vorgehen sollte , immer mit funktionierenden Tests an der Seite.
Alles in allem kann ich das Buch jedem empfehlen der sich ernsthaft mit Software-Entwicklung befassen will, der Preis sollte auch niemanden abschrecken. 5 Sterne !
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


18 von 19 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen anstoss zu mut, 14. Februar 2003
Von Ein Kunde
das buch zeichnet sich nicht so sehr dadurch aus, gutes design von grund auf zu lehren (patterns,...), sondern zeigt wege, aus vorhandenem, schlechten code in kleinen schritten zu besserem design zu kommen; es richtet sich auch an den design-profi, denn wie oft wird man mit "historisch gewachsenem" code konfrontiert, wuesste genau, wie das system vernuenftig designed werden muesste, und beginnt nie mit der sanierung, weil eben nie zeit fuer eine monatelange redesign-phase bleibt? so mueht man sich ewig und ungluecklich mit verwachsenen komponenten ab; fowler zeigt auf erstaunliche art und weise, wie mit kleinsten, derzeit machbaren schritten nennenswerte verbesserungen erreicht werden koennen, und gab mir den noetigen tritt in den a..., endlich was zu machen und nicht mehr ueber "nie bleibt zeit zum redesign" zu lavieren;
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


6 von 6 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen Ein Leckerbissen für OO-Programmierer, 26. Juni 2002
Eigentlich kommt es als Nachschlagewerk daher, doch hat es viel mehr als das zu bieten. Mit Hilfe dieses Buches habe ich gelernt, viel besser objektorientiert zu programmieren. Es hat mir die Augen geöffnet, wie mit automatischen Unit-Tests und Refactoring besserer Code entstehen kann. Keine Seite ist zuviel und man liest gerne jedes Kapitel auch noch ein zweites Mal durch. Weiter sind auch die Beispiele sehr treffend gewählt und helfen einem, die Materie zu verstehen und auch anwenden zu können. - Ein Muss für's Bücherregal.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


4 von 4 Kunden fanden die folgende Rezension hilfreich
4.0 von 5 Sternen Recipes for improving code, 5. Mai 2000
Von 
Sean Kelly "Consultant" (Dallas, TX USA) - Alle meine Rezensionen ansehen
(REAL NAME)   
Like the Gang of Four's landmark book _Design Patterns_, Fowler and his cohorts have created another catalog-style book, this time on refactoring.
Refactoring refers to taking existing, working software, and changing it about to improve its design, so that future modifications and enhancements are easier to add. _Refactoring_ is primarily a catalog of 70 or so different kinds of improvements you can make to object-oriented software.
Each entry in the catalog describes an implementation problem, the solution, motivation for applying the solution, the mechanics of the refactoring, and examples. The book's examples are all in Java, but C++ programmers should be able to approach the refactorings with ease. Often, Fowler diagrams the refactorings in UML, so a little Unified Modeling Language experience will help, too.
While the catalog is nice, the kinds of refactorings are obvious is most cases. Even moderately experienced programmers won't need the step-by-step mechanics described. The real benefit, though, is that the mechanics of each refactoring help guarantee that you can pull off the refactoring without introducing new bugs or side effects. They encourage you to take smaller, verifiable steps, than the more gross refactorings that most developers would naturally take. You actually save time doing so.
How do you know your refactorings are safe? Unit testing is the answer that Fowler et al. provide. Java developers will find the introduction to the Junit Testing Framework the most valuable part of the book, more so than the catalog of refactorings itself.
There's more to the book than the catalog and Junit, of course. There's discussion of the history of refactoring, how to evaluate refactoring tools, and how to convince management that what appears to be an overhead activity is actually useful in the long run.
Unfortunately, these sections are all too brief. And there is no discussion of how refactoring fits in with various software development processes. For example, programmers using Extreme Programming (XP) would probably feel right at home with Fowler's recommendations of refactoring in duets and unit testing, but developers stuck with a Software Engineering Institute process like PSP categorize testing as failure time and something to be minimized if not avoided. Cleanroom developers are taught that unit testing inteferes with metrics for quality, and that verifications are what should be done. Should such developers redo verifications after each refactoring? There's no answer in this book.
An unusual chapter, called "Bad Smells in Code," gives overall motivation for the refactorings. These vague notions, such as "long methods" or "lazy classes" humorously provide a foundation for starting your own refactorings. I say "humorously" because (mostly) Beck's and Fowler's odd analogies (classes becoming too intimate and delving in each others' private parts) provoke a chuckle (as if a chapter about "bad smells" in code weren't enough).
Overall, I've enjoyed reading this book and referring to the catalog while putting my own unit tests and refactorings into practice. Fowler's writing style is smooth and fluid, and it's easy to digest the catalog in no time. The book's typesetting is crisp, the figures quite clean, and both the refactoring index and "smell" index are enormously useful.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


3 von 3 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen A Unique Computing Book, 6. Juli 2000
Von 
Mr. V. J. O'Sullivan (London, England.) - Alle meine Rezensionen ansehen
(REAL NAME)   
Maintaining and modifying existing code is more important than most people realise. Commercially, it consumes more money than developing new code. Unfortunately, it seen as a drudge task and you'll be hard pushed to find much written about it. This book is an extraordinary exception.
It covers everything you to need to know about refactoring (improving hidden code whilst maintaining its visible interface). There is advice on when it should be done any many, many examples (templates) demonstrating pretty much every element of refactoring you're likely to need to perform.
Of particular note is the emphasis on testing, testing, testing. Athough it is not a book about testing several pages are dedicated to the subject. An introduction is made to his own mechanism for testing (JUnit) which enables code to be tested several dozen times per day without adding any overhead to the delivered code.
One of the final chapters is about 'Big Refactoring' where whole classes and not just individual methods are involved. It's a good introduction to the added risks and caution required but would benefit by some expansion.
Overall, the book is very well written. I read it from cover to cover and there are few computing books I'd try that with.
Finally, a word for the publishers. I have the hardback version an, as with all my Addison-Wesley books to date, it is well put together and should last a lifetime's regular use without falling apart.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


3 von 3 Kunden fanden die folgende Rezension hilfreich
3.0 von 5 Sternen Good addition, 28. Oktober 1999
Von Ein Kunde
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 Martin.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


2 von 2 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen gutes Nachschlagewerk und neue Impulse, 4. Juni 2011
Ich arbeite seit ca. 2 Jahren an einem Legacy System, was mittlerweile über zehn Jahre auf dem Buckel hat, und mit tausenden von Klassen gesegnet wurde. Seiner Zeit war es "State of The Art" jetzt wird es immer schwieriger es weiter zu entwickeln, da Generationen vor mir Änderungen vorgenommen hatten, die nicht unbedingt immer an der "richtigen" Stelle gelandet sind.

Ich brauchte neue Blickwinkel um das System wieder wartbar zu bekommen und bin über das Stichwort "Refactoring" auf dieses Buch gestoßen. Da es sich um ein Produktivsystem handelt kann man nicht einfach herangehen und einfach fröhlich die Sourcen verändern, doch mit jeder Neuentwicklung konnte ich nach und nach einzelne Module verbessern.

Einiges was in dem Buch steht, macht ein guter Entwickler intuitiv "richtig", doch bietet es an vielen Stellen weitere Lösungsansätze um die Code-Qualität weiter zu erhöhen.

Der Kauf hat sich für mich gelohnt, und ich schaue immer mal wieder rein, wenn ich neue Ideen entwickele.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


2 von 2 Kunden fanden die folgende Rezension hilfreich
4.0 von 5 Sternen Must read for any serious developer, 27. August 2009
Von 
M. Gärtner (Lage, Deutschland) - Alle meine Rezensionen ansehen
(REAL NAME)   
This book greatly covers a basis set of refactorings to clean up your code. During the regular test-driven development cycle of red-green-refactor you will use this often. In order to understand most of the refactorings in your IDE you will have to read this book. Though it covers the basic steps that most modern IDEs do for you to make the refactoring, it is still worthwhile to read and know when dealing with a tricky problem in a non-IDE supported language.

In addition to the description of the basic refactorings, you will get introduced into code smells. These are patterns that something is wrong with your code. There are indicators that you should - and most of the times you should do this urgently - refactor your code to a cleaner design.

Recommended reading as companion are the books Design Patterns and Refactoring to Patterns. In combination these three cover the most useful design ideas and how to get your today undesigned code to a cleaner one.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein


2 von 2 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen A future classic; ranks alongside _Design Patterns_, 30. November 1999
Von 
Forrest L. Norvell (San Francisco, CA USA) - Alle meine Rezensionen ansehen
(REAL NAME)   
It's rare that I find a technical book as immediately useful and fun to read as _Refactoring_. The cleverest thing about refactoring as a technique is that it provides a well-articulated, structured framework for doing something that every experienced developer does already (more or less unconsciously) -- constantly restructuring their code to make it easier to understand and maintain. This alone makes refactoring a useful contribution to software engineering.

However, Fowler doesn't stop there. He presents rationales for refactoring (with an eye towards making a case to management) and much detailed, practical insight that comes from experience, but is rarely expressed so concisely and elegantly. I also appreciated the importance Fowler placed on unit testing; in fact, using unit testing makes refactoring happen much more quickly, and leaves you with a lot more peace of mind besides.

I read the book cover to cover and enjoyed nearly every page. The book has added a lot to my value as a developer, and was a lot of fun in the bargain. I don't think a whole lot more needs to be said. Just buy it, you can thank everyone who told you to later.
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
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


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

Dieses Produkt

Nur in den Rezensionen zu diesem Produkt suchen