Fashion Sale Hier klicken Strandspielzeug Neuerscheinungen Cloud Drive Photos Learn More Slop16 Hier klicken Fire Shop Kindle PrimeMusic Summer Sale 16
Kundenrezension

173 von 209 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen Zu viel des Guten, 5. September 2009
Rezension bezieht sich auf: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) (Taschenbuch)
Von den begeisterten Rezensionen hier geleitet habe ich mir das Buch zugelegt und direkt gelesen. Vorneweg, der Schreibstil ist sehr angenehm, es liest sich hervorragend.

Die Punkte, die im Buch abgearbeitet werden um aufzuzeigen, was guter Code ist und ihn von schlechtem Code trennt decken sich mit meinen Erfahrungen, die Argumentationen, warum etwas schlecht ist und besser anders gemacht wird, nachvollziehbar. Bei den meisten Punkten stimme ich überein, doch was mir ziemlich sauer aufgestoßen ist:

* (Zu) Java-zentriert. Das ist an sich ja nicht so schlimm, würde man nicht bei den Argumentationen das ein oder andere mal - jedenfalls aber zu oft während des Buchs - denken, dass das Argument nur in Java Gültigkeit besitzt.
* Martin vergleicht ziemlich am Anfang des Buches die Aufbröselung langer Methoden mit der Normalisierung von Datenbanken. Offenbar hat er aber vergessen, dass sehr oft aber auch wieder Denormalisiert wird, da die weitere Auftrennung den Kontext auseinander reisst. Er hat zwar recht, dass man nach Möglichkeit alles auseinanderbricht, aber er verliert kein Wort darüber, dass man damit oft auch zu viel des Guten erreicht.
* Eine wichtige Grundregel meiner Erfahrung: Algorithmen _nicht_ auseinanderbrechen. Das schreckliche Gegenbeispiel kommt auf Seite 145, in dem Martin Knuths Primzahlencode aus Literate Programming nimmt, nach Java portiert und anschließend nach seinen Methoden refactort. Das Ergebnis ist eine reine Zumutung für das Auge und hat mit Clean Code nichts mehr zu tun. Positiv zu erwähnen ist, dass er die Ausgabe und die Erzeugung getrennt hat. Die Ausgaberoutinen sind sauber und so nachzuvollziehen, wie er es gern hat: Wie ein Stück Prosatext. Aber der Algorithmus als solcher ist nicht mehr zu erkennen. Nicht alles sollte als Prosatext beschrieben werden!
* Leider noch mal der Java Einfluss, aber wer von präzisem, klarem Code spricht, sollte keine Methodennamen verwenden, die länger als 20 Zeichen sind. Das Primzahlbeispiel macht das klar. Eine Methode mit Namen isLeastRelevantMultipleOfNextLargerPrimeFactor sollte nicht von jemandem geschrieben werden der von sich behauptet, sauberen Code zu schreiben... Code-Normalisierung ja, aber bitte nur soweit man keine Algorithmen, die irgendwo anders mathematisch beschrieben und geprüft sind, mit lächerlich anmutenden Funktionsnamen zerstört. Martins Code hat meistens eine gewisse Eleganz, aber die Eleganz in einem wohlgeformten Algorithmus scheint er nicht zu kennen, im Gegenteil, er reisst sie auseinander.
* Leider wird an keiner Stelle im Buch erwähnt, welchen Einfluss die Veränderung des Quellcodes auf die Performance der Software hat. Dass er es mit der Performance in seinem Code nicht all zu ernst nimmt zeigt ein Beispiel, bei dem er einen String zurück gibt, in dem ein Großbuchstabe einen Schalter der auf an steht anzeigt, und einen Kleinbuchstaben, wenn der Schalter aus ist. Normal würde man das über ein Bitfeld machen, und nicht wie er vorschlägt besser mit StringBuffer. Leider lässt der Java Einfluss wieder grüßen.

Ich bin etwas enttäuscht von dem Buch. Bei vielen Stellen im Buch hab ich den Kopf geschüttelt und mir die Frage gestellt, was für ein Schmarrn das ist, was er da macht, da das so einfach nicht in allen Bereichen applikabel ist. Wer viel in Java programmiert wird seine Freude an dem Buch haben und sicher oft mit dem Kopf nicken. Wer unter Clean Code nicht (nur) maximal-aufgebrochene Funktionen mit elendig langen Funktionsnamen versteht wird mit dem Buch nicht glücklich und lediglich seine Vorurteile über Javaprogrammierer bestätigt finden. So jemand schaut sich besser nach anderen Büchern um und reicht das Buch an den fanatischen Javajünger in seinem Freundeskreis weiter ;)
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

[Kommentar hinzufügen]
Kommentar posten
Verwenden Sie zum Einfügen eines Produktlinks dieses Format: [[ASIN:ASIN Produkt-Name]] (Was ist das?)
Amazon wird diesen Namen mit allen Ihren Beiträgen, einschließlich Rezensionen und Diskussion-Postings, anzeigen. (Weitere Informationen)
Name:
Badge:
Dieses Abzeichen wird Ihnen zugeordnet und erscheint zusammen mit Ihrem Namen.
There was an error. Please try again.
">Hier finden Sie die kompletten Richtlinien.

Offizieller Kommentar

Als Vertreter dieses Produkt können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
Der folgende Name und das Abzeichen werden mit diesem Kommentar angezeigt:
Nach dem Anklicken der Schaltfläche "Übermitteln" werden Sie aufgefordert, Ihren öffentlichen Namen zu erstellen, der mit allen Ihren Beiträgen angezeigt wird.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.  Weitere Informationen
Ansonsten können Sie immer noch einen regulären Kommentar zu dieser Rezension veröffentlichen.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
 
Timeout des Systems

Wir waren konnten nicht überprüfen, ob Sie ein Repräsentant des Produkts sind. Bitte versuchen Sie es später erneut, oder versuchen Sie es jetzt erneut. Ansonsten können Sie einen regulären Kommentar veröffentlichen.

Da Sie zuvor einen offiziellen Kommentar veröffentlicht haben, wird dieser Kommentar im nachstehenden Kommentarbereich angezeigt. Sie haben auch die Möglichkeit, Ihren offiziellen Kommentar zu bearbeiten.   Weitere Informationen
Die maximale Anzahl offizieller Kommentare wurde veröffentlicht. Dieser Kommentar wird im nachstehenden Kommentarbereich angezeigt.   Weitere Informationen
Eingabe des Log-ins
  [Abbrechen]

Kommentare

Kommentare per E-Mail verfolgen
Von 8 Kunden verfolgt

Sortieren: Ältester zuerst | Neuester zuerst
1-10 von 17 Diskussionsbeiträgen
Ersteintrag: 13.09.2009 03:17:49 GMT+02:00
Filmfreak meint:
Danke für diese Kommentare. Ich dachte schon ich bin der einzige, der so denkt. Das Buch ist gut und bietet viele Interessante Ansätze. Generell würde ich mir wünschen, dass mehr Entwickler sich Gedanken um dies Lesbarkeit ihres Codes machen würden. Aber dieses Buch schießt oft kompromisslos übers Ziel hinaus.

Ich kenne Leute, die das Buch gelesen haben und jedes Wort befolgen, als ob es für sie die Bibel der Programmierung ist. Seit dem ist ihr Code zwar "systematischer", aber nicht unbedingt besser zu verstehen. Völlig zerstückelt und mit teilweise unsinnigen zusätzlichen Variablen versehen - nur damit man es wie ein Buch lesen kann. Ich brauche nun oft doppelt so lange um deren Code zu verstehen. Um den Sinn einer eigentlich recht simplen Funktion nachzuvollziehen muss ich mich nun mit dutzenden kleiner Hilfsfunktionen herumschlagen, die oft nur eine oder max zwei Zeilen echten Code enthalten. Natürlich hat jedes Programm-Statement eine funktionale Bedeutung - das bedeutet aber nicht dass man man es tatsächlich eine "Function" im Sinne der Programmstruktur ist. Insbesondere, wenn man unzählige kleine private Funktionen hat, bei denen die Funktionsdeklaration umfangreicher ist, als der Funktions-Code, und die jeweils nur an einer Stelle im Code aufgerufen werden, sollte man noch einmal darüber nachdenken.

Über die Performance braucht man gar nicht zu reden. Wenn jede Software so geschrieben wäre, würde man schon für einfache Programme eine High-End-Maschine benötigen. Ganz zu schweigen davon, dass es grauenhaft ist Ausnahmen zu Debuggen, deren Stack-Trace länger ist, als der ausgeführte Code, der zur Ausnahme geführt hat.

Ich habe vor kurzen einen Blog-Beitrag gelesen, in dem ein Entwickler ein Stückchen Code aus seinem praktischen Alltag exakt nach den Anforderungen in diesem Buch umformuliert hat. Das was am Ende aus den wenigen (und eigentlich leicht verständlichen) Code-Zeilen geworden ist, war eine Katastrophe. Der Umfang war auf ein vielfaches angewachsen und im Gegensatz zur Urform reichte nicht mehr nur ein Blick, um den Sinn zu verstehen. Und ja, das Buch ist leider sehr auf Java beschränkt. Unter dem Titel hätte ich mir allgemeinere Ansätze gewünscht. "Clean Java-Prose-Code: Turn your Program into a novel." wäre ein zutreffender Titel gewesen. Man sollte das Buch lesen und es als Inspiration verstehen, aber nicht blindlings all das umsetzen, was der Autor vorschlägt/fordert.

Veröffentlicht am 18.10.2010 22:50:44 GMT+02:00
Ecky meint:
Ich finde Ihre Argumentation interessant. Mit zerstückelten Code komme ich auch nur sehr schwer zurecht. Jedoch habe ich auch noch nicht so viel Erfahrung und würde nun gern mal ein Buch lesen dem ich vertrauen kann.
Können Sie denn ein Java Buch empfehlen, welches mir zeigt wie ich guten Code schreiben soll?
Denn irgendwie gibt es bei jedem Buch negative Rezensionen.

Antwort auf einen früheren Beitrag vom 08.11.2010 14:57:37 GMT+01:00
Seferis meint:
Hallo Ecky,
also zum Einstieg, was Java-Programmierrichtlinien angeht, sollte man zunächst mal das hier lesen:
http://www.oracle.com/technetwork/java/codeconv-138413.html
Und dann den Autoformatierer seiner bevorzugten IDE nicht vergessen (in Eclipse z.B. <Strg><Shift><f>).

Darüberhinaus hilft meiner Meinung nach gesunder Menschenverstand:
1. mnemonische Bezeichner vergeben, wenn es sich nicht nur um Laufvariablen/Indizes handelt.
2. sobald Funktionalität an mehr als einer Stelle verwendet wird, kein Copy+Paste von Code (Anti-Pattern), sondern diese Funktionalität möglichst in eigene Methode/Funktion auslagern.

Veröffentlicht am 14.03.2011 22:52:12 GMT+01:00
[Vom Autor gelöscht am 18.03.2012 11:29:56 GMT+01:00]

Veröffentlicht am 11.04.2011 13:21:35 GMT+02:00
Zuletzt vom Autor geändert am 11.04.2011 13:22:48 GMT+02:00
Bert Speckels meint:
Hallo

ich kann Ihrer Kritik durchaus folgen und habe selbst häufig so empfunden. Was ich nicht ganz verstehe: Es scheint mir so, als seien Sie der Meinung, die Kritik würde für Java-Entwickler nicht relevant sein ... vielmehr seien viele kritierte Aspekte im Lichte von Java durchaus sinnvoll?! Dem kann ich nun garnicht zustimmen. Auch in Java sind weder überlange Methodennamen üblich noch ist die Verwendung von Strings anstatt boolescher Werte sinnvoll.

Veröffentlicht am 15.04.2011 12:59:04 GMT+02:00
miranto meint:
Die Zeit der Lochkarten ist vorbei. Man hat also keine absolute Begrenzung mehr, was die Anzahl der Zeichen pro Zeile/Statement betrifft, und gerade die aktuellen Breitbildmonitore bieten eine Menge Platz. Deshalb sind Grundsätze wie, dass kein Name länger als 20 Zeichen sein darf, nicht mehr aktuell. Wenn die Bezeichnung einer Methode also mal länger wird, ist das immer noch besser, als wenn schwer lesbare Abkürzungen verwendet werden oder wichtige Informationen weggelassen werden.

Antwort auf einen früheren Beitrag vom 18.04.2011 10:36:05 GMT+02:00
Zuletzt vom Autor geändert am 20.04.2011 10:26:23 GMT+02:00
G. E. Scheidt meint:
Ich weiß nicht Herr Ziel, wie lange Sie schon Software entwickeln (nur Java?). Bei mir sind es schon einige Jahrzehnte in verschiedensten Sprachen. Für Leute die Ihre Programme nur aus kleinen Methoden in Eclipse zusammenklicken, damit sie die jeweiligen Probleme irgendwie lösen, ohne die Philosophie der verwendeten API zu verstehen, ist das Buch goldrichtig.

Ich kann mich der Rezension von Herrn Waniek nur anschließen. Ich finde den relegiösen Eifer, mit dem bestimmte Java Developer anderen ihre "Designphilosophie" aufdrücken wollen, sehr befremdlich (man sehe sich die Homepage der "Clean Code Developer" Fraktion mal an). Man sehe sich auch die absolut overdesignte Java I/O API mit ihren dutzenden wirren Klassen an. Das passiert, wenn man den gesunden Entwicklerverstand ausschaltet und statt dessen massiv auf coole neue Designtechniken setzt.

Die Zukunft wird spannend. Es gibt immer mehr Leute, die sich ihr ganzes Programmiereleben NUR mit Java beschäftigt haben und sich ganz sicher sind, als sogenannte Enterprise Architekten, den vollen Überblick zu haben.

Eigentlich sollte man über diese Entwicklung glücklich sein. Bessere Arbeitsbeschaffungsmaßnahmen für die kommenden Jahre und Jahrzehte gibt es nicht.

Antwort auf einen früheren Beitrag vom 18.04.2011 14:35:45 GMT+02:00
[Vom Autor gelöscht am 18.03.2012 11:30:08 GMT+01:00]

Antwort auf einen früheren Beitrag vom 07.07.2011 15:24:39 GMT+02:00
[Vom Autor gelöscht am 20.01.2014 15:53:55 GMT+01:00]

Antwort auf einen früheren Beitrag vom 07.07.2011 15:40:42 GMT+02:00
Nach wie vor gilt jedoch, dass eine Funktion eine Sache tun sollte, und die richtig. Wenn man dies beherzigt und mal ein wenig aus der OOP Welt rausschaut und sich umblickt, was es da sonst noch gibt (z.B. funktionelle Sprachen) und sich auch davon inspirieren lässt wird man stetig bemüht sein möglichst knappe, korrekte Funktionen ohne Seiteneffekte zu entwickeln. Daraus resultieren meist sowieso schon keine Funktionen mit unangenehm langen Namen.

Zu dem anderen Kommentar hier: Ich habe lange genug Quellcode anderer lesen, korrigieren und refactoren müssen die ungefähr genau so programmieren wie in dem Buch vorgeschlagen. Resultat: Kein Zuckerschlecken, im Gegenteil...
‹ Zurück 1 2 Weiter ›