Buch-Rezension zu “Practical Object-Oriented Design in Ruby”

Ein gutes Buch über objektorientiertes Design (OOD) zu finden ist nicht einfach. Obwohl sich viele Bücher diesem Thema widmen fehlt doch immer wieder etwas: Entweder ist das Buch so theoretisch das es keinen Bezug zur Praxis hat oder die notwendige Theorie fehlt.

“Practical Object-Oriented Design in Ruby” (kurz POODR) von Sandy Metz findet den Mittelweg zwischen Theorie und Praxis. In einer direkten Sprache wird man Schritt für Schritt an die Thematik OOD herangeführt.
Auch wenn die Beispiele in Ruby sind so ist dieses Buch auch für andere Sprachen sehr zu empfehlen – das benötigte Wissen über Ruby ist minimal und schnell erklärt.

 

Wozu OOD?

Sandy Metz definiert OOD als die Art und Weise wie man Code in einem Programm anordnet. OOD ist somit nicht nur etwas für Experten sondern betrifft jeden Programmierer. Denn jeder der Code schreibt beeinflusst dessen Design.

Design is more the art of preserving changeability than it is the act of achieving perfection.

Ob eine Erweiterung später einfach einzubauen ist hängt von den heute getroffenen Entscheidungen ab. Oft fehlt aber die Erfahrung und das Wissen wie sich Entscheidungen auswirken. Dieses Buch zeigt einem wie kleine Veränderungen die Erweiterbarkeit beeinflussen und was für Vor- und Nachteile die einzelnen Ansätze von OOD mitbringen. Dies ersetzt zwar nicht das Sammeln von eigenen Erfahrungen, bietet einem aber eine gute Ausgangslage um nicht alle Fehler selber machen zu müssen.

 

Einfache Beispiele

Nach all den Banken und Blogs kommen hier Fahrräder für die Beispiele zum Einsatz. Durch die Optimierung für E-Reader sind die Beispiele recht kurz. So lässt sich der Code übersichtlich darstellen und ist als Nebeneffekt einfach zu verstehen. Im Gegensatz zu anderen Büchern kann man sich so auf die Beispiele konzentrieren und muss nicht ständig hin und her blättern.

Das entscheidende bei den Beispielen ist der Weg zum Ziel. Daher gibt es entsprechend viele kleine Schritte die ausführlich erläutert werden. Allerdings führen nicht alle Schritte in die richtige Richtung. Umwege und falsche Ansätze werden in diesem Buch ebenfalls thematisiert und erklärt.
So kann man auf wenigen Seiten Erfahrungen sammeln die bei einem richtigen Projekt Monate an Arbeit verursachen.

 

Tests

Dem Thema Tests widmet sich das letzte Kapitel. Die in den vorherigen Kapiteln erarbeiteten Beispiele werden hier nun getestet. Man sieht so rasch wie die verschiedenen Ansätze von OOD sich auf die Testbarkeit von Code auswirken.

Sehr gelungen finde ich wie die Stolperfallen präsentiert werden. Der Mock für die Tests mag noch so gut sein. Wenn sich die Klasse ändert und der Mock dies nicht mitbekommt ist zwar der Test grün aber die Software läuft nicht. Die gezeigten Lösungen sind zwar auf dynamisch typisierte Programmiersprachen ausgerichtet, können aber auch bei C# beim Erkennen von Veränderungen helfen.

 

Was fehlt

Die gewählten Beispiele sind alle recht Kurz und meist weniger als 100 Zeilen lang. Auch wenn kurze Klassen und Methoden anzustreben sind so ist die Realität doch oft anderes. Ein längeres Beispiel bei dem man mittels OOD Ordnung hinein bringt hätte ich sehr begrüsst.

 

Weitere Informationen

Wer sich für OOD interessiert aber nicht gleich ein Buch dazu lesen will wird auf Confreaks fündig. Dort gibt es als Video abrufbare Präsentationen von Sani Metz die einzelne Konzepte aus dem Buch aufgegriffen.

Wer lieber Podcasts hört findet in Episode 87 von Ruby Rogues eine ausführliche Buchbesprechung mit zahlreichen Tipps rund um OOD die im Buch keinen Platz gefunden haben.

 

Fazit

POODR ist ein angenehm zu lesendes Buch das sehr viel Wissen vermittelt. Obwohl ich mich schon länger mit OOD beschäftige konnte ich hier ganz neue Aspekte kennen lernen. Die Beispiele sind so einfach das man davon nicht abgelenkt wird und doch komplex genug um all die verschiedenen Möglichkeiten zu erklären.

Für mich ist dieses Buch definitiv ein „Must Read“ für alle die sich mit Software-Entwicklung beschäftigen.

 

Zum Buch

“Practical Object-Oriented Design in Ruby” von Sandy Metz, 2012 Addison-Wesley Professional, ISBN: 978-0-3217-2133-4, 272 Seiten, Englisch

Buch-Rezension zu “Domain-Driven Design”

Wenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
“Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. “Man müsse die Informationen herausschürfen” ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern “Anticorruption Layer”).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book “Domain Driven Design Quickly“. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus “Applying DDD” von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. “Domain Driven Design Quickly” ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

“Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

Buch-Rezension zu “Build Awesome Command-Line Applications in Ruby”

“Build Awesome Command-Line Applications in Ruby: Control Your Computer, Simplify Your Life” von David Copeland erschien im März 2012 bei The Pragmatic Programmers. Anwendungen für die Kommandozeile zu schreiben scheint in Zeiten von HTML 5 und Cloud Computing ein sinnloser Zeitvertreib zu sein. Dem ist aber nicht so.

Will man seine täglichen Arbeiten automatisieren und Abläufe vereinfachen sind Kommandozeilenprogramme mit einer ganz spezifischen Aufgabe von grossem Wert. Das einfache Interface und der Verzicht auf ein GUI ist da kein Nachteil, sondern ein Motivator um noch mehr zu automatisieren.

 

2 Tätigkeiten als Ausgangspunkt

Copeland steigt mit 2 alltäglichen Aufgaben ins Thema Kommandozeilenprogramme ein:

1. Ein Backup-Tool für MySQL
2. Eine ToDo-Verwaltung

Beide Aufgaben sind schon in unzähligen Büchern erklärt worden und so kann man sich eine grosse technische Einführung ersparen. Die Seiten werden stattdessen für ein genaues ausleuchten der unterschiedlichen Aspekte verwendet. Beim Backup-Tool liegt der Schwerpunkt in der Konfigurierbarkeit während es bei der ToDo Anwendung mehr um die Benutzerführung geht.

Im Verlauf des Buches werden die beiden Anwendungen ständig ausgebaut. Man erfährt dabei die Motivation hinter vielen Kommandozeilenprogrammen der UNIX-Plattformen, wieso diese so gut zusammenarbeiten und welche Erweiterungsmöglichkeiten sich für eigene Werkzeuge bieten.

 

Gute Werkzeuge erstellen

Was macht ein gutes Werkzeug aus? Und worauf soll man achten? Obwohl jeder Entwickler hier wohl unterschiedliche Schwerpunkte setzt ist die Auflistung von David Copeland mehr als nur ein guter Start. Seine Anforderungen an ein gutes Werkzeug sind:

• löst ein klar definiertes Problem
• ist einfach zu verwenden
• unterstützen den Benutzer
• arbeitet mit anderen Anwendungen zusammen
• stehen Gelegenheitsnutzern nicht im Weg
• ist einfach zu konfigurieren
• lässt sich leicht verteilen
• kann ohne grossen Aufwand erweitert werden

Zu all diesen Punkten wird gezeigt wie man diese meist mit geringem Mehraufwand erfüllen kann. Seine Tipps helfen einem dabei nicht jedes Mal von vorne beginnen zu müssen. Und oft sind es nur ganz kleine Dinge wie ein passender Kommentar in der Hilfe der einem später unzählige Stunden an Arbeit ersparen kann.

 

Selber bauen mit Methadone

Hat man erst einmal die Möglichkeiten kennen gelernt möchte man wohl selber anfangen so hilfreiche Anwendungen für die Kommandozeile zu schreiben. Damit man sich auf die interessanten Teile konzentrieren kann schrieb Copeland das Gem Methadone. Dies lässt sich wie alle anderen Gems einfach installieren und kann sogleich für eine neue Anwendung verwendet werden:

gem install methadone
methadone newgem

Mit dem zweiten Befehlt wird das Grundgerüst für die eigene Anwendungen erstellen. Neben allen Abhängigkeiten für die testgetriebene Entwicklung wird auch gleich die gewählte Lizenz hinterlegt und alles zum paketieren vorbereitet. Die detaillierte Anleitung mit allen Optionen findet sich auf der Projektseite von Methadone.

 

Fazit

David Copeland liefert mit seinem Buch praxisbezogene Tipps um alltägliche Aufgaben mit Ruby zu automatisieren. Abgesehen von ein wenig Ruby wird kaum Wissen vorausgesetzt und alles kompakt aber verständlich erklärt.

Beim realisieren eigener Kommandozeilenanwendungen ist das Buch ein gutes Nachschlagewerk und hat mir schon oft geholfen. Ich kann dieses Buch daher ohne Vorbehalte weiterempfehlen.

 

Zum Buch

“Build Awesome Command-Line Applications in Ruby: Control Your Computer, Simplify Your Life” von David Copeland, 2012 The Pragmatic Programmers, ISBN 978-1-9343-5691-3, 224 Seiten, Englisch

Buch-Rezension zu “The Rails View”

“The Rails View: Create a Beautiful and Maintainable User Experience” von Bruce Williams und John Athayde erschien im April 2012 bei The Pragmatic Programmers. Zu Ruby on Rails gibt es unzählige Bücher, doch bisher fehlte es an einem Buch das sich dem View-Layer annimmt. Diese Lücke wollen Williams und Athayde mit ihrem Buch schliessen.

Um dem Buch folgen zu können sollte man sich mit CSS und JavaScript auskennen. Es wird kein grosses Wissen vorausgesetzt, aber ganz ohne geht es nicht.

 

Aufbau

Im Buch wird eine Rails-Anwendung Schritt für Schritt ausgebaut. Die Autoren folgen dabei der Häufigkeit der Arbeiten und gliedern ihr Buch in diese Kapitel:

• Das Layout der Anwendung erstellen
• Die Lesbarkeit erhöhen
• CSS hinzufügen
• JavaScript hinzufügen
• Wartbare Formulare erstellen
• Presenters nutzen
• Mobile Views erstellen
• E-Mails erzeugen
• Performance optimieren

 

Viele praktische Hilfen

Gerade bei den „einfachen“ Themen wird oft ein simpler Weg gezeigt und anschliessend ein Ansatz, der zwar komplexer ist aber einem einen deutlich besser zu pflegenden Code liefert. Ich fand das Gegenüberstellen der Ansätze sehr hilfreich um zu erkennen worauf man achten sollte.

Es gibt viele Tricks mit denen man mit CSS und JavaScript seine Rails-Anwendung aufpeppen kann. Mit diesem Buch bekommt man einen Einblick in die Möglichkeiten und ist in der Lage eine deutlich angenehmere Benutzerführung zu erstellen als was einem Rails mit seinen Generatoren von Haus aus liefert.

Der Einsatz von Helpern und Presentern fand ich einen eleganten Ansatz um Code aus der View zu extrahieren. Weniger Code in der View ermöglicht einem sich auf das zu konzentrieren was dort wichtig ist – die Ausgabe der Informationen.

 

Verbesserungsmöglichkeiten

Bei den Beispielen scheint es einem ab und zu noch an Informationen zu fehlen die in einem späteren Kapitel erklärt werden. Wer das im Buch vorgestellte gleich Schritt für Schritt in seine Anwendung übernehmen will wird so bald einmal vor Probleme gestellt. Da das Buch doch recht viele Themen behandelt wäre es praktisch wenn jedes Kapitel für sich alleine funktionieren würde.

Will man nach dem Lesen im bereitgestellten Code etwas nachschauen muss man sehr viel suchen. Der Aufbau der Ordnerstruktur hätte man gerne ein wenig nachvollziehbarer gestalten können.

 

Fazit

“The Rails View” liefert einem eine gute Übersicht über die für den View-Layer relevanten Technologien. Das Buch zeigt auf wie man mit JavaScript und CSS eine angenehme Benutzerführung realisieren kann und dabei nicht auf die Lesbarkeit seines Codes verzichten muss.

Wenn das Buch auch keine grundlegende Einführung in die vorgestellten Technologien liefert, so gelingt es den Autoren zu zeigen wie man diese mit Rails kombinieren und nutzen kann.

 

Zum Buch

“The Rails View: Create a Beautiful and Maintainable User Experience” von Bruce Williams und John Athayde, 2012 The Pragmatic Programmers, ISBN 978-1-9343-5687-6, 264 Seiten, Englisch

Buch-Rezension zu “The Art of Readable Code”

“The Art of Readable Code” von Dustin Boswell und Trevor Foucher erschien Ende 2011 bei O’Reilly. Auf rund 200 Seiten bekommt man viele Tipps um den eigenen Code lesbarer zu machen. Dies dient nicht nur anderen Programmierern, sondern hilft einem auch selber – spätestens in einigen Wochen wenn man nicht mehr alle Details im Kopf hat.

Die vorgestellten Tipps & Tricks sind dabei nicht auf eine bestimmte Programmiersprache oder Framework-Version beschränkt. Wer in C# entwickelt wird genauso brauchbare Tipps finden wie derjenige der JavaScript verwendet.

 

Viele gute Empfehlungen

Durchs Buch hinweg wird jeweils mit einem kurzen Beispiel gezeigt wie massiv sich eine kleine Änderung auswirken kann. Das Codebeispiel zu Beginn ist dabei nicht extra unleserlich gemacht worden. Es könnte viel eher aus einem eigenen Projekt stammen.

Die im jeweiligen Kapitel behandelte Empfehlung wird für den Leser leicht nachvollziehbar in kleineren Teilschritten umgesetzt. So sieht man einerseits dass auch der eigene Code verbesserungspotential hat und andererseits wie wenig Veränderung es braucht um viel zu verbessern. Damit das gerade gelernte haften bleibt gibt es immer einen extra hervorgehobenen Satz (Key Idea) der die Empfehlung genau auf den Punkt bringt.

Die behandelten Themen lassen sich grob in diese Bereiche unterteilen:

• Aussagekraft erhöhen (bei Namen, Kommentaren oder mittels Formatierung)
• Vereinfachen (nicht nur die Logik an sich, sondern auch Schleifen und if-Bedingungen)
• Reorganisieren (weil kleinere Teile einfacher zu verstehen sind)

Besonders gefallen haben mir die immer wieder eingeworfenen Beispiele aus der Praxis. Nur weil einem gerade kein perfekter Kommentar einfällt kann man ja nicht den ganzen Tag danach suchen. Irgendwie muss die Entwicklung ja voran gehen. Die beiden Autoren tragen dem Rechnung und zeigen wie man sich schrittweise einem besseren Kommentar nähern kann.

 

Nicht blind folgen

Auch wenn dieses Buch bei vielem richtig liegt, so gibt es auch einige Empfehlungen die einem recht schnell vor neue Probleme stellen können. Mich störte dabei vor allem die Empfehlung für statische Methoden. Im Einzelfall mag dies ein guter Tipp sein, bei zu intensiver Anwendung leidet aber die Testbarkeit. Daher führt auch bei diesem Buch kein Weg daran vorbei mitzudenken und eine Balance zwischen allen Anforderungen zu finden.

 

Fazit

Ein kompaktes Buch mit vielen Vorschlägen um Code lesbarer zu schreiben. Obwohl es an revolutionären Neuerungen fehlt so ist es erfrischend ein Buch zu diesem Thema zu finden das frei von Dogmen ist.

Gegenüber “Clean Code” findet man hier kaum Neues. Wem Clean Code aber zu theoretisch oder zu abgehoben war sollte es mit diesem Buch versuchen.

 

Zum Buch

“The Art of Readable Code” von Dustin Boswell und Trevor Foucher, 2011 O’Reilly, ISBN 978-0596-8022-95, 206 Seiten, Englisch