“Kann ich diesen Code ändern?” klingt nach einer ganz üblichen Frage im Projektalltag, aber meiner Meinung nach bringt diese Frage ein großes Problem im agilen Entwicklungsprozess ans Tageslicht.

Vorab: Die Frage ist sehr gut, zeigt sie doch die heeren Absichten ihres Stellenden: Verbessere gefundenen Code. Ständige Verbesserung ist eine der wichtigsten Grundsätze bei der Erstellung von sauberem Code. Aber die Frage an sich zeigt, daß etwas dem Fragesteller besorgt. Etwas steht in seinem Weg, ansonsten hätte er den Code einfach geändert. In Scrum nennt man dies ein “impediment” welches gelöst werden muss, aber auch nicht Scrum Projekte sollten dieses Problem lösen. Nebenbei sei erwähnt, daß das Lösen konkreter Fallbeispiele nicht reicht. Das Problem sollte grundsätzlich angegangen werden damit die Frage nicht mehr gestellt werden muss.

Im Folgenden einige von mir als Problemursachen identifizierte Sachverhalte und Lösungsideen:

• Der betroffene Code ist nicht zugänglich oder aus politischen gründen tabu ⇒ Überzeugt Eure Teams, daß gemeinsame Verantwortlichkeit für Code vorteilhaft für alle ist. Es geht insbesondere nicht darum bestimmte Verantwortlichkeiten anderer Teams zu übernehmen. Außerdem sind die meisten Entwickler sowieso vorsichtig bei solchen Änderungen. Insofern braucht man sich nicht vor der “common code ownership” zu fürchten.
• Das Refactoring bricht existierende API ⇒ Für die meisten Projekte ist das garkein so großes Problem wie oft dargestellt. Normalerweise wird die API nur intern verwendet und eine neue API könnt auch viel besser benutzbar sein. Selbst wenn die API extern verwendet wird ist eine kontrollierte Änderung durchaus möglich.
• Der Entwickler traut seinen Fähigkeiten nicht ⇒ Die IT Welt verlangt nach kontinuierlichem Lernen und Veränderung und eigentlich mögen es sogar viele Entwickler an neuem Unbekannten zu arbeiten. Es ist völlig okay zögerlich zu sein, aber frische Ideen können alten Code besser oder robuster machen. Pair Programming mit dem ursprünglichen Ersteller des Codes, oder einem anderen erfahrenen Entwickler im Team hilft hierbei oft die Angst vor Änderungen zu nehmen. Und für den Fall, daß doch etwas passiert gibt es ja Tests…
• Nichtvorhandene Tests machen Änderungen riskant ⇒ Es ist wichtig Zeit in das Schreiben von Tests zu investieren um das aktuelle Verhalten des Codes zu verifizieren und sicherzustellen, daß es mit dem Verhalten nach der Änderung identisch ist. Schwieriger ist es, wenn in der Änderung auch Verhalten geändert werden soll. Dann hilft es meist nur mit einem Architekten mögliche Implikationen zu diskutieren oder herauszufinden wer den Code aktuell überhaupt verwendet.
• Die genaue Verwendung des Codes ist unbekannt ⇒ Ein möglichst umfassendes Architekturbild und so viel Code abhängiger Projekte wie möglich helfen die Auswirkungen von Änderungen abzusehen. Für Entwickler wäre ein Refactoringsetup der Entwicklungsumgebung mit sämtlichem Code hilfreich. IDEs bieten viele Refactoringtools und können die meisten Verwendungen von Code aufspüren. Größere Refactorings können auch auf eigenem Branch und unter Beobachtung durch ein Continous Integration system durchgeführt werden.
• Aber es gibt kein Backup… ⇒ Oh, immer noch kein Versionskontrollsystem? Dies sollte schleunigst geändert werden.

Code verändern ist gut, da wir alle Code besser oder schöner machen wollen. Es hilft Lösungen verständlich und einfach zu halten. Wenn man die Ursachen wie Fehler oder Designschwächen nicht verbessert werden andere Entwickler anfangen diese mit Workarounds in ihrem Code zu umschiffen. Dies führt zu einer unschönen und nicht wartbaren Verschwendung von Bytes.

Mein Appell an alle Entwickler:
“Scheut Euch nicht mit guten Absichten fremden Code zu verbessern.”

Mein Appell an Projektleiter und Scrum Master:
“Macht das Ändern fremden Codes schmerzfrei”

Um mit einer aktuell allgegenwärtigen Phrase die Frage im Titel dieses Betrages zu beantworten:
“Yes, you can!“

Neal Ford hielt am Dienstag auf der JAX einen Talk über DSLs und was sie uns für Vorteile bringen. Er zeigt, daß Java bei der Unterstützung für DSL Notationen recht schnell an seine Grenzen stößt und wechselte daher für seine Beispiele dann zu Ruby. Aber da wir bei codecentric hauptsächlich uns mit Java beschäftigen, habe ich mir mal angesehen was möglich ist und was man damit eigentlich tun kann. Einige Entwickler haben bereits das neue Builder pattern von Josh Bloch mittels eines fluid Interfaces umgesetzt. Aber dieses Pattern hat ein Problem: das sogenannte “finishing problem”. Weil das Builder pattern mittels verketteter Methoden arbeitet und Werte via Rückgabeparameter übergibt sind zu verschiedenen Zeitpunkten bestimmte Werte noch nicht initialisiert. Neal zeigte ein von jMock inspiriertes Beispiel wie man dieses Problem in Java lösen kann. Dies inspirierte mein folgendes Beispiel, welches so oder so ähnlich auch schon von GWT oder Swing Entwicklern verwendet wird.

Mein Java DSL Beispiel

Session ormPitfalls = new Session() {{
	speaker("Mirko");
	attending("Fabian");
	attending("a lot of other people");
	at("Rheingoldhalle");
	at(new JaxDate() {{
		day2();
		session2();
	}});
}};

Auf den ersten Blick sieht dies nicht besonders ungewöhnlich aus. Aber… Oh.. doppelte geschweifte Klammern?? Der hier verwendete Trick ist eine  anonyme Klasse, welche Session erweitert (genauso bei JaxDate etwas weiter). Nachdem der Standard Konstruktor ausgeführt wurde laufen die sogenannten Initializer Blocks. Dieser Initializier, welcher in geschweiften Klammern geschrieben wird, enthält nun Methodenaufrufe in einer DSL im Kontext Session.

Braucht man das?

Genauer gesagt hat dieses Vorgehen sogar probleme. Jede Instanz hat seine eigene Klassendefinition, welche zur Laufzeit erstellt werden muss, was eine etwas längere Erstellungszeit nach sich zieht. Ausserdem ist der Speicherverbrauch etwas größer und getClass().getName() liefert natürlich einen anderen Namen.

Und zuletzt bleibt natürlich die große Frage: Wollen wir wirklich, daß Fachabteilungen in Produktion laufenden Code mittels einer DSL schreiben?

Aber…

… es gibt eine gute Verwendung: Testen! Sehr gerne sähen wir mehr Fachabteilungen am Testen beteiligt, aber selbst mit guten Tools gibt es immernoch einen großen Aufwand an Mocks und Dummies welche erstellt werden müssen. Der oben gezeigte Code um Objektinstanzen zu erstellen ist aber sehr verständlich. Tester können die Domänenmethoden verwenden anstelle sich mit der Erzeugung von Datumsobjekten durch die Java Calendar API rumschlagen zu müssen. Ausserdem ist der Code viel lesbarer und besser. Bis jetzt würde die zu testende und die testende Methode jeweils über eigenen Code ein Datum berechnen. Da es aber keinen Test für den Test gibt wird nicht verifiziert, daß die Datumsberechnung ok ist. Im obigen Beispiel ist die Datumsberechnung jedoch nur einmal implementiert.

Kleiner Calendar Exkurs

Da ich gerade beim Calendar bin. Wie berechnent man “morgen mittag”? So?

Calendar today = Calendar.getInstance();
today.setTime(calendar.getTime());
today.add(Calendar.DAY_OF_YEAR, 1);
today.set(Calendar.HOUR_OF_DAY, 12);
today.set(Calendar.MINUTE, 0);
today.set(Calendar.SECOND, 0);
today.set(Calendar.MILLISECOND, 0);

Das sieht nicht nur hässlich aus, sondern hat auch teilweise falsche Semantik. Besser wäre:

Calendar calendar = GregorianCalendar.getInstance();
Calendar today = calendar.clone();
today.setTime(calendar.getTime());
Calendar tomorrow = today.clone();
tomorrow.add(Calendar.DAY_OF_YEAR, 1);
Calendar tomorrowNoon = tomorrow.clone();
tomorrowNoon.set(Calendar.HOUR_OF_DAY, 12);
tomorrowNoon.set(Calendar.MINUTE, 0);
tomorrowNoon.set(Calendar.SECOND, 0);
tomorrowNoon.set(Calendar.MILLISECOND, 0);

uhh.. zumindest versucht dieser Code den Zwischenzuständen korrekte Namen zu geben. Wenn dieser Code aber in einer Methode namens tomorrowNoon() in unserem CustomCalendar/Date Objekt wäre, würde die Semantik viel besser sein (die Methode arbeitet dann nur auf “this.“), insbesondere ist der Code vor dem Anwender versteckt.

Fazit

Domain Specific Languages sind sehr interessant; insbesondere in Programmiersprachen welche eine noch freundlichere Notation erlauben. Jedoch ist die Zeit in vielen Projekten noch nicht reif. Für Tests hingegen stellen sie schon jetzt ein probates Mittel dar um Fachabteilungen mit einzubeziehen und Testcode les- und wartbarer zu machen. Generell ist es immer hilfreich Methodennamen sprechend zu wählen und die Funktionalität an der Fachdomäne auszurichten..

Trotz der Krise konnte die JAX 2009 die Teilnehmeranzahl im Vergleich zu 2008 in etwa halten – das war eine wichtige Aussage bei der Begrüßung der Teilnehmer durch Sebastian Meyen. Aus meiner Sicht kann man das auch sehen – es sind wieder viele Firmen auf der begleitenden Messe vertreten und auch die Schlangen an den Catering Tischen sind nicht kürzer geworden.

codecentric ist dieses Jahr Silber Sponsor und wir konnten unseren Messestand, nicht ganz ohne Stolz, deutlich vergrößern.

Insgesamt sind wir mit acht Leute auf der JAX – natürlich auch um die aktuellen Trends und Technologien aufzunehmen und selber Präsentationen zu halten. In diesem Jahr halten wir auch selber drei Vorträge. [1, 2, 3] zu unseren Kernthemen Agilität und Java Performance.

An unserem Stand kann man sich vor Allem zu unserem Meet the Experts informieren und an der Performance Studie 2009 teilnehmen – wie auch im letzten Jahr erfreut sich gerade die Studie großer Beliebtheit. Das Ergebnis der Performance Studie 2008 kann man sich bei uns am Stand in gedruckter Form kostenfrei abholen.

Gestern habe ich mir einige Sessions zum Thema “neue Sprachen” auf Basis der Java Plattform angehört – aus meiner Sicht einer der “Hypes” auf der JAX. Dazu habe ich aber schon gestern einen Beitrag für Jaxenter mit dem Titel “Turmbau zu Babel” geschrieben und möchte das hier nicht wiederholen.

Ein weiterer interessanter Vortrag zum Thema “Event Driven Architecture” von Clemens Utschig-Utschig hat mir sehr deutlich aufgezeigt, dass EDA in Zukunft eine entscheidende Rolle in Verbindung mit Serviceorientierten Architekturen spielen wird. Gerade bei Anwendungsfällen wo die Performance Anforderungen sehr hoch sind und Prozessvarianten nur schwer zu modellieren sind, haben EDAs einen entscheidenden Vorteil. Die Infrastruktur und Technologien für EDAs sind im Prinzip auch schon vorhanden und werden vor allem im Finanzbereich und auf Flughäfen bereits eingesetzt – meistens aber auf Basis eigener Implementierungen. Clemens  zog deshalb auch das Fazit, dass in Zukunft Best Practises und Standards für EDAs entwickelt werden müssen, um sie in bestehenden Anwendungen “salonfähig” zu machen.

Neben diesen Themen beherrschte natürlich die mögliche Übernahme Sun’s durch Oracle die Gespräche der Teilnehmer. Meine persönliche Meinung ist, dass es im Prinzip nur gut sein kann für Java. Sun war meiner Meinung nach immer ein Hardware Unternehmen, das mit Java nicht wirklich viel anfangen konnte -  Sun konnte beispielsweise auch keine namhafte kommerzielle Software in diesem Bereich etablieren und der Application Server Markt wird heute von IBM und Oracle aufgeteilt. (natürlich mit Open Source Alternativen wie JBoss, Tomcat oder Glassfish) Oracle wird sicherlich mehr aus der Java Plattform machen – die Integration von Firmen wie BEA und Tangasol in die Oracle Fusion Middleware zeigen dabei auch, dass eine Übernahme sehr positive Effekte auf die Produkte haben kann. Gerade der von mir sehr geschätzte Gründer von Tangasol, Cameron Purdy, äußert sich in seinem Blog immer sehr positiv über die Arbeit unter Oracle Fahne und gerade er ist sicherlich kein Weichspüler. Interessanter ist aus meiner Sicht eher die Frage was Oracle mit MySql machen wird – hier denke ich wird es negative Veränderungen geben.

Was mich persönlich “nervt” ist der Twitter Hype auf der JAX, der gerade von den Speakern als eine Art religiöse Form der Kommunikation geprisen wird. Stefan Roock twittert sogar live in seiner Session…ich glaube es dauert noch was, bis ich den Hype verstanden haben.

InnoDB war bislang die populärste Storage Engine von MySQL, da die MyISAM Engine auf Grund vieler Limitationen nicht überzeugen konnte und nur in Randgebieten Einsatz fand. MySQL AB entwickelte einige Zeit an Falcon, der Nachfolgerengine für InnoDB und MyISAM.
Nachdem MySQL von Sun übernommen wurde und der Chefarchitekt von Falcon das Team verließ, stand es schon schlecht um MySQL. Nach der Ankündigung von Oracle Sun kaufen zu wollen wurden die Karten wieder erneut gemischt.
Doch um MySQL steht es meiner Meinung nach schlecht, insbesondere seit nun InnoDB als eigenständige Datenbank veröffentlich wurde. Das Produktportfolio von Oracle im Datenbankbereich ist damit nun noch undurchsichtiger und umfangreicher. Wurde noch kürzlich darüber spekuliert ob MySQL als “kleines Oracle” überleben kann, so ist dies meiner Meinung nach wirklich fragwürdig. Für MySQL spricht wenig. Für InnoDB, welches de facto den Großteil der “MySQL” Installationen ausmacht spricht deutlich mehr. InnoDB lässt sich gut neben den alten Oracle Produkten positionieren. Für Clusterfähigkeit muss es dann wohl schon bald ein echtes “Oracle” sein.

Aber die genaue Zukunft ist noch ungewiss. Dennoch ist jetzt der richtige Zeitpunkt die eingesetzte Datenbanklandschaft mal auf Einsatzweck und verwendete Features zu prüfen. Oracle wird nach der Übernahme das Produktportfolio anpassen, und wir sind dann bereit.

Gestern habe ich den Agile Day auf der JAX 2009 in Mainz besucht. Es würde nicht viel Sinn machen, wenn ich irgendwelche Bewertungen zu den Vorträgen abgeben würde, da ich einer der Speaker war … … aber ich möchte hier einige persönliche Eindrücke weitergeben, die ich gesammelt habe.

Als erstes war ich sehr überrascht, wie viele Besucher der Agile Day hatte. Es waren mindestens 300 Leute, die den ganzen Tag über dageblieben sind. Das hat mir auf eindrucksvolle Weise gezeigt, wie sehr die Leute derzeit an dem Thema Agilität interessiert sind. Bei einer kurzen Umfrage hat etwa die Hälfte der Teilnehmer gesagt, dass sie einige agile Praktiken nutzen, aber nicht wirklich agil sind. Von der anderen Hälfte haben die meisten Leute gesagt, dass sie derzeit gar nichts in Sachen Agilität machen, aber an dem Thema interessiert sind. Nur eine Handvoll Leute hat angegeben, dass sie wirklich agile Software-Entwicklung betreiben und die meisten von ihnen waren Speaker. Mir hat das gezeigt, dass noch eine weite Reise im Bereich Agilität vor uns liegt, aber dass sich viele Leute mittlerweile auf den Weg gemacht haben, was ein gutes Zeichen ist.

Die zweite für mich interessante Sache war eine Pecha Kucha Session. Stefan Roock hatte diese Session organisiert. Es waren 6 Speaker, von denen jeder eine Präsentation mit exakt 20 Folien gezeigt hat, von denen jede genau 20 Sekunden angezeigt wurde, zusammen 6 Minuten und 40 Sekunden. So sind die Regeln für eine Pecha Kucha Präsentation. Das war für mich ziemlich interessant, eine solche Session zu besuchen. In der Vergangenheit habe ich zwar schon darüber gelesen, aber gestern habe ich das erste Mal an einer solchen Session teilgenommen. Gefallen hat mir die Dauer der Präsentationen. Sie zwingt die Vortragenden, sich auf eine oder maximal zwei Ideen zu fokussieren und hält sie davon ab, langwierig über dutzende Dinge zu reden. Auf der anderen Seite fand ich das strikte Format recht ablenkend. Meistens sind die Folien ein wenig zu lang oder zu kurz für den vorgetragenen Inhalt des Speakers angezeigt worden. So mussten sie wechselweise oft warten oder sich sehr beeilen. Zusätzlich war ich stark abgelenkt, da ich irgendwie immer darauf gewartet habe, wann die nächste Folie angezeigt wird. Zusammenfassend war es eine recht interessante Erfahrung für mich, aber ich denke, dass dieses sehr strikte Format nur in wenigen Fällen wirklich hilfreich ist. Meiner Meinung nach sind kurze Sessions – 10 Minuten oder weniger – ein gutes Format, aber sie sollten nicht so strikt sein.

Meinen letzten interessanten Eindruck hatte ich bei dem Speaker Panel am Ende. Es war nicht die Panel Diskussion an sich, davon habe ich mittlerweile eine Menge gesehen. Es war vielmehr die Tatsache, dass selbst die agilen Experten, die dort gestanden haben, recht unterschiedliche Ansichten und Auffassungen zu dem Thema Agilität hatten. Okay, auf der einen Seite ist das sicherlich ziemlich normal für viele Themengebiete, aber auf der anderen Seite ist es immer wieder recht überraschend, das live in einer Panel Diskussion zu erleben. Für mich bin ich zu dem Schluss gekommen, dass Agilität insgesamt ein noch nicht sehr gut erforschtes Gebiet ist und dass sich das Thema in den nächsten Jahren noch ziemlich weiterentwickeln wird.