Hier klicken Sale Salew Salem Öle & Betriebsstoffe für Ihr Auto Jetzt informieren Books Summer Shop 2017 Cloud Drive Photos Learn More TDZ Matratzen Hier klicken Mehr dazu Mehr dazu Shop Kindle AmazonMusicUnlimited AmazonMusicUnlimited longss17
Kundenrezension

86 von 94 Kunden fanden die folgende Rezension hilfreich
4.0 von 5 Sternen Stellenweise zu dogmatisch, daher -1 Stern., 20. August 2009
Verifizierter Kauf(Was ist das?)
Rezension bezieht sich auf: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) (Taschenbuch)
Ich habe einige Kapitel gelesen und will mir noch kein abschliessendes Bild machen. Das was die anderen Rezensenten sagen, stimmt schon. Es ist wirklich ein gutes Buch über gepflegten Code. Nur an ein paar Stellen wird mir der Autor zu dogmatisch, deswegen sollte man nicht alles blind übernehmen. Am deutlichsten wurde mir das im Kapitel 3 über Funktionen.

Dort beschreibt er anhand einer unaufgeräumten Funktion wie er sie schrittweise verbessert, und gibt dabei den ersten Zwischenschritt und das finale Ergebnis preis. Dabei erstellt er im Zwischenschritt eine absolut verständliche, klare Funktion mit 11 Codezeilen und beschreibenden Funktionsaufrufen. Damit ist der Autor aber nicht zufrieden, bezeichnet die Funktion absurderweise als immer noch "too long" und legt nochmal Hand an, indem er fast jede Zeile in eine eigene Funktion packt. Der daraus resultierende Code hat fast doppelt soviele Zeilen wie der ursprüngliche Code den es zu verbessern galt! Der Autor wünscht sich, das sich der Code wie eine Geschichte lesen soll, zerstückelt ihn dabei aber derart das man meint man würde nun ein Buch lesen in dem auf jeder Seite nur ein Satz mit maximal 10 Worten steht. Ich kann seine Begeisterung für derart zerstückelten Code absolut nicht nachvollziehen, zumal die Bezeichnung der Funktionen immer abstruser wird, da nun nicht mehr nur 5-10 Funktionen sondern eher 25 nach einer sinnvollen Beschreibung verlangen. Ganz zu schweigen davon das man vom Einstiegspunkt aus nun jeden Funktionsübergang mitlesen muss, indem man die aufgerufene Funktion sucht, dort den nächsten Funktionsaufruf vorfindet, um sehr schnell nicht mehr zu wissen auf welchem "level" des callstacks man sich nun befindet. Im Kopf ist sowas nur noch schwer zu durchschauen, und Debugger-freundlich ist das auch nicht mehr.

Ergo: mir hat der Zwischenschritt mit 11 Zeilen wesentlich besser gefallen, er war auf jeden Fall auf einen Blick verständlich und nachvollziehbar. Darauf wollte ich hingewiesen haben, denn hier wird der Autor dogmatisch und schießt sich selbst ins Knie, in dem er seine Argumentationen ad absurdum führt und dennoch sehr deutlich darauf beharrt was für wunderschönen Code er daraus gezaubert hat. Dieser Dogmatismus ist es auf den ich hinweisen wollte, und wegen dem ich auch einen Stern abziehe.
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 2 Kunden verfolgt

Sortieren: Ältester zuerst | Neuester zuerst
1-4 von 4 Diskussionsbeiträgen
Ersteintrag: 28.08.2009, 22:00:57 GMT+2
Zuletzt vom Autor geändert am 28.08.2009, 22:02:46 GMT+2
Hans Wurscht meint:
Update: sehr schön finde ich wie er mit dem Mythos "guter Code ist gut dokumentiert" aufräumt. Nein, guter Code ist nicht dokumentiert. Guter Code braucht das nicht. Schön seziert welche Art von Kommentaren es gibt und warum sie überflüssig, nicht hilfreich, störend usw. sind. Sehr viel Kopfnicken erntete das automatisierte dokumentieren von Code, aus denen dann API Referenzen erzeugt werden die im Grunde nur die Klassen und Methoden listen, aber keine Hilfe sind. Und eben auch im Code nur stören.

Eine andere Stelle wo er mir dann doch wieder zu dogmatisch wird hatte ich auch noch gefunden, kann die aber nicht mehr wiederfinden bzw. mich daran erinnern.

Veröffentlicht am 10.09.2010, 22:22:34 GMT+2
Zuletzt vom Autor geändert am 10.09.2010, 22:33:19 GMT+2
pd meint:
The degree to which you should refactor your code depends to the specific situation. If further refactoring doesn't add to clarity, performance or maintainability of your code, you should leave it as it is. But if you emphasize the code testability, it could be beneficial to break the code further apart. The reason is that the key to testable code is isolation. Testing many simple functions (as opposed to testing a single complex function) allows you to pinpoint the bugs with very little effort; If you test simple functions and a test fails, it is obvious where to look for the bug. On the other hand, if you have a function consisting of, say, 50 lines of code than you have 50 potential locations where the bug might be.

To conclude, I am not evangelizing the "clean code" way. My message is that from a certain perspective, e.g. testability, it could make sense to refactor a 10 lines function into 5 seperate functions.

Veröffentlicht am 13.03.2012, 17:02:48 GMT+1
Jepp, hab genau dasselbe gedacht..wer alles aus dem Buch 1:1 übernimmt kann sich eingraben - filtern hilft. Aber es sind wahnsinnig viele kleine Sachen dabei, über die ich mir noch nie explizit Gedankekn gemacht hab. Deswegen machts Lesen Spaß.

Veröffentlicht am 11.08.2012, 19:31:55 GMT+2
Patches meint:
pd hat hier meiner Meinung nach völlig Recht - und "Onkel Bob" macht bereits im Vorwort deutlich, wie er das Buch gerne aufgefasst sehen möchte; Dazu gehört nicht, die explizit als "richtig" herausgearbeiteten Ideen zu Dogmen hochzustilisieren - dass es verschiedene "Schulen" gibt beschreibt er ebenso wie er beschreibt, dass man eben nicht alles übernehmen muss.

Dazu kommt, dass Bob Martin eben auch ausdrücklich schreibt, dass sauberer Code seiner Meinung nach (!) Tests enthält; Und hier greift wieder ein Teil des von pd geschriebenen: "testautomatisierter" Code besteht eben aus extrem kleinen Funktionen, da jede Funktion nur genau eine Sache erledigen soll und darf (und daraufhin auch getestet wird).

Zum Lesen des Codes wie eine Geschichte: Ich verstehe das so, dass sauberer Code am Ende dadurch klar wird, dass wir als Leser und Informatiker zuerst den eigentlichen Ablauf ohne Implementierungsdetails nachvollziehen können und uns dann immer tiefer in die Details vorwagen. Bei entsprechend gewählten Funktionsnamen kann das dann wirklich schon fast dem Lesen eines Artikels etc. entsprechen. Der Blick auf das "Hauptprogramm" offenbart keinerlei Details, sondern nur die Zusammenhänge und Abläufe. Hier gehen wir dann immer tiefer.

Zumindest verstehe ich seine Ausführungen so.

Dass man bei keinem Buch, keiner "Schule", keinem Prozessmodell immer und überall alles 1:1 übernommen werden sollte, halte ich für selbstverständlich. Teilweise geht das einfach nicht, teilweise ist es nicht gewünscht, teilweise gehen die Meinungen und Geschmäcker auseinander ... so what? ;)
‹ Zurück 1 Weiter ›