Archiv

Archive for Mai 2010

Buch-Rezension zu “Refactoring”

Refactoring: Improving the Design of Existing Code” von Martin Fowler erschien 1999 bei Addison-Wesley. Mit diesem Buch gelang Fowler ein Standardwerk, dass trotz seines Alters nichts an Aktualität eingebüsst hat.

 
Was ist Refactoring?
Als Refactoring bezeichnet man die Verbesserung der Struktur von Programmcode bei der die Funktionalität nach aussen hin nicht verändert wird. Diese Restrukturierung dient einer besseren Lesbarkeit, besserem Verständnis und der Erhöhung der Wartbarkeit. Dadurch können Erweiterungen an bestehendem Code leichter und schneller eingefügt werden.

Fowler beginnt das Buch nach einer kleinen Begriffserklärung mit einem Beispiel zur Gebührenberechnung für ausgeliehene Videos. Dieser kleine Anwendungsfall zeigt schön wie man schrittweise mittels Refactoring die Qualität von Code erhöhen kann. Und es weckt das Interesse, mehr darüber zu erfahren.

 
Grundsätzliches über Refactoring
Wann soll man es nutzen und wo liegen die Grenzen? Dies versucht Fowler im zweiten Kapitel zu beantworten. Seine Antwort darauf lautet, dass man es eigentlich immer machen sollte. Es gibt zwar einige Ausnahmen (wenn z.B. ein Neuschreiben des Codes weniger Aufwand verursacht), doch in der Regel ist Refactoring eine sinnvolle und notwendige Tätigkeit.

Einige Refactorings sind für die Performance nicht gerade förderlich. Fowler empfiehlt erst den Code aufzuräumen und danach die Performance anzugehen. Der gesäuberte Code ist in der Regel einfacher und effektiver zu optimieren. Natürlich gilt auch hier, das man immer auch selber denken darf. Blind einem Refactoring zu folgen nur weil es im Buch steht macht keinen Sinn.

 
Tests sind wichtig
Nach einer kurzen Auflistung der grössten “Bad Smells” und wieso diese nach einem Refactoring rufen geht es ums testen. Um sicherzustellen das sich an der Funktionalität nichts geändert hat, sind Tests unverzichtbar. Dieses Sicherheitsnetzt gibt einem die Freiheit, ohne grosses Nachdenken über mögliche Konsequenzen das Refactoring durchzuführen. Muss man ständig jede mögliche Auswirkung bedenken, kann man kaum noch produktiv arbeiten. Hat man aber Tests, passen diese auf und liefern schnell eine verlässliche Bestätigung. Bevor man sich in die Arbeit stürzt, sollte man unbedingt ein wenig Zeit in gute Tests investieren – es zahlt sich sehr schnell aus.

 
Der Katalog
Fowler hat 72 Refactorings gesammelt und immer nach diesem Format beschrieben:

  • Name: damit man eine Basis für die Kommunikation hat und unter der gleichen Bezeichnung auch das gleiche versteht
  • Zusammenfassung: wozu dieses Refactoring dient.
  • Motivation: eine ausführlichere Erklärung wann man dieses Refactoring anwenden kann und wann man es sein lassen sollte.
  • Ablauf: eine Schritt für Schritt Anleitung um das Refactoring durchzuführen.
  • Beispiel: ein möglichst einfaches Beispiel das beim Verstehen des Refactorings hilft.

Die Refactorings reichen vom sehr einfachen extrahieren einer Methode über Templates bis zu Design Patterns. Manche davon gehen auf Smalltalk zurück und waren schon seit mehr als einem Jahrzehnt bekannt, andere wurden erst von wenigen Leuten um Fowler herum verwendet.

Bei zahlreichen Refactorings gibt es auch eine Gegenaktion. Auf “Extract Method” folgt zum Beispiel “Inline Method”. Je nach Situation ist das eine oder andere Refactoring nötig um zu besserem Code zu kommen. Der Katalog hilft einem bei der Umsetzung, aber der Entwickler trifft die Entscheidung, welchen Weg er einschlagen will.

 
Fazit
Die Schreibweise von Fowler hat mir sehr gefallen. Ohne grosses Tamtam erklärt er das sehr wichtige Thema und regt zum nachdenken an. Bei diesem Buch machte ich häufig eine Lesepause um gerade gewonnene Erkenntnisse und Ideen aufzuschreiben.

Neben dem eigentlichen Thema lernt man auch sehr viel über Objektorientierung. Etliche Feinheiten von denen ich bisher das “wie” kannte haben dadurch nun eine ganz neue Erklärung für das “wieso” bekommen. Auch wenn die Beispiele in Java sind, so gelten diese fast vollständig auch für jede andere (Objektorientierte-) Programmiersprache.

Ich kann jedem Programmierer dieses Buch empfehlen – es ist definitiv ein “Must-Read”.

 
Zum Buch
Refactoring: Improving the Design of Existing Code” von Martin Fowler, 1999 Addison-Wesley, ISBN 978-0-201-48567-7, 464 Seiten

Schlagworte: ,

Wieso ich gerne bei Brack.ch einkaufe

Anfangs April bestellte ich mir Komponenten für einen neuen PC. Wie immer machte ich dies bei Brack.ch. Die Lieferzeiten sind dort enorm kurz und auch preislich ist das Angebot sehr gut.

Beim einbauen der RAM stellte ich leider fest, das egal wie ich die Module drehe, diese einfach nicht passen wollen. Ich überprüfte ob das was ich bestellte auch geliefert wurde. Die Bezeichnung der RAM war die gleiche wie auf dem Lieferschein, der Bestellbestätigung und auf der Webseite.

 
Was ein fehlendes “non-” so alles machen kann
Da ich den Fehler nicht finden konnte, rief ich die Technik-Hotline von Brack an. Der sehr freundliche Techniker konnte mir gleich helfen. Ich hatte RAM mit ECC statt non-ECC bestellt. Der Error Correction Code ( oder kurz ECC) würde dabei helfen Bitfehler zu beheben. Nur brauchen diese einen anderen Steckplatz als ihn das Mainboard anbietet. Somit hatte ich nun RAM die mir nichts nützen.

Ich hatte allerdings Glück. RAM ist eines der Produkte, die zurückgenommen werden können. Einfach zurückschicken und ich würde eine Gutschrift erhalten. Im gleichen Anruf ich konnte auch die korrekten RAM bestellen, um diese tags darauf abzuholen.

Die Rückgabe in Mägenwil verlief so einfach wie am Telefon angekündigt. Der Hinweis ich solle die ursprüngliche Rechnung (mit all den anderen Teilen) erst bezahlen wenn ich die Gutschrift in der Hand halte, würde ich befolgen.

Nach rund 3 Wochen war die Gutschrift bei mir und ich bezahlte die Rechnung. In der Konto-Übersicht im Webshop konnte ich sehen, dass alles wie erwartet verbucht wurde. Wenn es am Ende auch ein wenig länger dauerte, so ist alles wie angekündigt abgelaufen.

 
Eine positive Erfahrung
Mich hat das Verhalten von Brack positiv überrascht. Obwohl es mein Fehler war, wurde alles unternommen um für mich eine Lösung zu finden. Was mir am Telefon erzählt wurde hat dann auch am Schalter und mit der Buchhaltung genau so funktioniert. (Dies grenzt in der heutigen Zeit schon fast an ein Wunder.)

Bei diesem super Kundenservice bin ich gerne bereit ein wenig mehr für die Produkte zu bezahlen. Daher ein grosses DANKE von mir für das Team von Brack!

Schlagworte:

Buch-Rezension zu “Test-Driven Development”

Test-Driven Development By Example” von Kent Beck erschien 2002 bei Addison-Wesley. Kent Beck erklärt die testgetriebene Entwicklung von Software anhand von 2 Beispielen. Gewissermassen eine Pair-Programming Lektion in Buchform.

 
Zum Inhalt
Der erste Teil des Buches widmet sich dem Money-Beispiel in Java. Die zu erstellende Klasse soll verschiedene Geldbeträge in unterschiedlichen Währungen verrechnen können. Die Problemstellung des Beispiels ist für jeden verständlich und dennoch genügend komplex, um den Vorteil von TDD aufzeigen zu können.

Im zweiten Teil erstellt Kent Beck ein xUnit Testrunner in Python. So wird testgetrieben ein Programm zum automatischen ausführen von Tests geschrieben. Man wird am Ende nicht wirklich viel von Python verstehen, aber es liefert einen interessanten Einblick in die Funktionsweise eines xUnit-Tools.

Der dritte Teil behandelt Patterns für Test-Driven Development. Hier wird aufgezeigt, wie sich TDD mit anderen Themen integrieren lässt. Seien dies Mocks, Fakes, Commits die sauber und kompilierbar sein müssen bis hin zur Erinnerung an Auftraggeber, das Programmierer auch Menschen sind und man vielleicht ein wenig Geld für bequeme Stühle ausgeben könnte…

 
Stärken
Kent Beck gelingt es sehr gut die Grundprinzipien von TDD zu zeigen. Wie geht man vor? Was bedeutet zuerst testen nun konkret? Beck erstellt sich zuerst eine Liste mit Aufgaben und arbeitet diese ab. Taucht etwas wichtiges auf, das aber nicht gleich angegangen werden kann, wird es aufgenommen. Diese sehr einfache Methode hilft beim zielgerichteten vorgehen und liefert einem einen guten Überblick über den Fortschritt.

Es gelingt ebenfalls gut zu zeigen wie man vorgehen kann, wenn nicht alle Anforderungen zu Beginn des Projekts klar sind. Schrittweise zu verfeinern ist die einzige Alternative zum warten bis alles klar ist. Sind die Tests gut und möglichst frei von Redundanzen, hat man ein brauchbares Fundament für die nächsten Schritte.

Ich konnte viel bei der Schrittgrösse lernen. Wenn klarer ist, wo man hin muss, kann man schneller gehen und mehr mit einer Iteration machen. Ist die Anforderung unklar, geht es halt nur in Babysteps vorwärts. Dieses dynamische variieren gab mir einige weitere Inputs die mir zur Komplettierung meines Verständnis von TDD noch fehlten.

Ebenfalls gut war der Hinweis, dass man den eingeschlagenen Weg abbrechen soll, wenn man erkennt, dass dieser nicht dorthin führt, wo man hin will. Nicht lange darüber nachdenken und auch nicht krampfhaft versuchen, es doch noch hin zu bekommen. Ein sauberer Schnitt und man kann hinter die richtige Lösung.

 
Schwächen
Der Code wird Teil für Teil erzeugt, doch fehlt am Ende leider ein Abdruck wo all die Teile zusammen abgebildet werden. Wie die einzelnen Klassen am Ende aussehen wird man nur herausfinden wenn man die Beispiele 1 zu 1 nachprogrammiert. Fürs Verständnis wär es hilfreich gewesen, nicht nur die Code Metriken aufzulisten, sondern die 91 Zeilen Code abzudrucken. Diese 2 zusätzlichen Seiten hätten sehr viel gebracht.

Einige der gezeigten Beispiele verursachen Magenschmerzen. Bei Pluggable Selector wird versucht, zahlreiche Subklassen zu vereinen, die sich nur im Ausgabeformat der Methode print() unterscheiden. Die erste Alternative erinnert einem sehr stark an das Beispiel, das die Anti-IF Campaign benutzt. Hier ist es zwar ein Switch-Statement, aber genauso problematisch.
Das 2. Beispiel nutzt Reflection, was es auf 2 Zeilen reduziert. Nun ist es zwar kurz, aber keiner versteht mehr was gemacht wird – ausser man beschäftigt sich länger mit der Methode, was sicher nicht der Sinn der Sache sein kann. Von all den Seiteneffekten ganz zu schweigen. Ein solch unnötiges und schlechtes Beispiel verwirrt nur und hätte weggelassen werden können.

Der Wechsel von Java zu Python und im Anhang wieder auf Java hätte man meiner Meinung nach auch sein lassen können. Der ungewohnte Syntax von Python stört beim Verständnis der Beispiele mehr als er nutzt. Ohne weiteres hätte man das Beispiel zu xUnit auch in Java machen können.

 
Fazit
TDD by Example behandelt die Arbeitsweise der testgetriebenen Entwicklung. Das Buch ist sehr gut um zu zeigen, wie am Ende alles zusammenpasst. Allerdings fehlt zu viel von den technischen Grundlagen um mehr zu machen als einfache Beispiele. Dazu sind Test Driven und The Art of Unit Testing deutlich besser geeignet. Die 3 Bücher ergänzen sich von dem her recht gut.

Ist das Buch ein Must-Read? Das ist schwer zu sagen. Ich fand es gut um einige offenen Fragen zu beantworten. Diese finden sich sicher auch in den anderen beiden Büchern, wenn auch nicht so gut wie hier. Mir gefiel aber der Stil von Kent Beck und so habe ich davon profitieren können.

Am besten wirft man vor dem Kauf einen Blick ins Buch. Gefällt einem der Stil und die Beispiele, sollte man es sich kaufen. Andernfalls verpasst man nicht wirklich viel.

 
Zum Buch
Test-Driven Development By Example” von Kent Beck, 2002 Addison-Wesley, ISBN 978-0-321-14653-3, 240 Seiten

Schlagworte: , ,
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 254 Followern an