Es gibt aber auch Dinge in Java oder der API, die haben mich in den letzten acht Jahren immer wieder wahnsinnig werden lassen. Beispielsweise der Umgang mit Zeitangaben. Allein, daß sich Calendar im Package java.util befindet, drückt doch schon eine gewisse Geringschätzung aus...

Wer Businessanwendungen schreibt hat es täglich mit Zeitangaben in seinen Anwendungen zu tun wie: jeden Tag um acht Uhr, sieben Stunden lang oder vom ersten bis zum zehnten jeden Monats. Für all das bietet das JDK nur Date und Calendar als Ausdrucksmittel. Beide Klassen beziehen sich vereinfacht gesagt immer auf einen konkreten Zeitpunkt unter Angabe von Tag und Uhrzeit. Beides stellt also einen festen Punkt auf einer Zeitachse dar.

Damit lassen sich aber die oben genannten Beispiele nicht ausdrücken. "Vom ersten bis zum zehnten" bezieht sich auf zwei Punkte auf der Zeitachse. Sollen Fragen wie "Liegt folgendes Datum im Zeitraum oder davor oder sogar danach?" zwingt uns die API immer mit zwei Datumsangaben zu hantieren. Sollen zwei Datumsangaben mit Calendar noch schnell mit Tages oder Monatsgenauigkeit überprüft werden, läßt sich das auch nicht in einer Zeile bewerkstelligen, da Calendar-Instanzen immer auch Zeitangaben enthalten.

Eine neue API für den Umgang mit Zeit ist also mehr als überfällig und Rettung naht auch schon in Form des JSR 310 Date and Time API der unter der Leitung von Stephen Colebourne und Michael Santos entwickelt wird.

Colebourne ist übrigens auch verantwortlich für das JodaTima-Projekt, welches heute schon eine alternative API für Zeitberechungen bereitstellt und von http://joda-time.sourceforge.net/ heruntergeladen werden kann.

Die Grundkonzepte von JodeTime sind die folgenden Datentypen:

• Instant für einen Punkt auf der Zeitachse mit Nanosekundenauflösung
• Interval für einen Zeitraum zwischen zwei Punkten auf der Zeitachse
• Duration für eine Zeitdauer in Milisekunden wie zum Beispiel 3 Tage
• Period für Zeitdauerangaben unter der Verwendung von Jahren, Monaten etc. vergleichbar mit xs:duration

Um diese Datentypen bauen Colebourne und Santos nun auch die API für den JSR 310 auf die eventuell schon in der 7er Version von Java unter javax.time enthalten sein wird. Dazu kommen die notwendigen Klassen zur Verarbeitung von Datumsangaben. Insgesamt hinterläßt die API einen sehr mächtigen Eindruck. Zur Zeit ist sie leider noch sehr instabil, wer aber die Mailingliste zum JSR 310 verfolgt, merkt das aktiv an der Spezifikation und Implementierung gearbeitet wird. Einen guten Überblick über die verfolgten Ziele liefert auch die Präsentation von Colebourne auf der 2008er JavaOne.

Wer bis zu Version 7 nicht warten will, kann jetzt schon bei JodaTime Hilfe finden.

Josuttis schreibt darin über einem Vortrag auf der Agile 2008 zum Thema Software-Qualität, der von Robert C. Martin gehalten wurde. Martin stellt fest, daß wir in der Software-Branche zu viel Mist produzieren. Vorallen tun wir das, weil einfach zu wenig Zeit dafür zur Verfügung steht um sauber zu arbeiten zwischen all den Budgetplänen, Tagessätzen und Releaseterminen. Insofern ist das Sujet bekannt und die meisten von uns können das wohl aus der einen oder anderen Erfahrung bestätigen.

Das eigentlich interessante ist, daß Josuttis das wohl aus eigener Erfahrung kennt und auch darlegt, wie er versucht diesem Problem beizukommen und damit glatt die nächste Revolution in der IT-Welt vorhersagt.

Josuttis versucht dem Problem beizukommen, in dem die Entwicklung von Fachlichkeiten vom „Sauermachen“ trennt. Es gibt also zwei Gruppen. Die einen schreiben fleißig Code und die anderen bringen ihn in Ordnung. Schlechter Code ist demnach in Ordnung, da er später glattgezogen wird. An die großen Hypes Agilität und SOA anknüpfend entwickelt er diesen Gedanken weiter und stellt die Frage, warum wir nicht endlich schlechten Code akzeptieren, schließlich haben wir mit der Agilität sich wandelnde Anforderungen akzeptiert und sogar kultiviert und SOA das gleich mit heterogenen Systemen getan. Schlußendlich sollten wir aufhören, schlechten Code zu bekämpfen, sondern sinnvoll damit umgehen.
So sehr er mit vielem auch Recht hat, umso mehr irrt er hier doch und kommt zu einem falschen Schluß. Schlechter Code ist zu bekämpfen.

Eine allgemein gültige Definition von gutem Code gibt es nicht. Daher für aber viele von Qualität. Mir gefällt am besten die DIN-Definition, wonach Qualität „die Beschaffenheit einer Einheit bezüglich ihrer Eignung, festgelegte und abgeleitete Erfordernisse (Qualitätsanforderungen) zu erfüllen“ ist. Zugegebener Maßen klingt das etwas sperrig und erschließt sich nicht direkt, denn was sind „abgeleitete Erfordernisse“. Qualität hat viele Ausprägungen, wie da wären:

• Funktionalität
• Zweckdienlichkeit
• Sicher
• Robustheit
• Benutzbarkeit
• Zuverlässigkeit
• Änderbarkeit
• Portierbarkeit
• Prüfbarkeit
• Geschwindigkeit

Jeder wird zugeben, daß eine Software, die nicht die geforderten Funktionen bringt aus Kundensicht nichts wert ist. Insofern ist Funktionalität ein hinreichendes Qualitätsmerkmal, aber allein nicht ausreichend. Je länger eine Software lebt, umso wichtiger werden auch Merkmale wie Wartbarkeit und Änderbarkeit und können zum Schluß mehr über den Erfolg Ihrer Software entscheiden als die eigentliche Funktionalität.

Natürlich muß man am Code verzweifeln, wenn man die perfekte Architektur und eine konsistente Einhalt von Codierrichtlinien erwartet und hofft, daß alle Entwickler den gleichen Stil pflegen und sich mit der gleichen Hingabe ihrer Aufgabe widmen. Die Welt ist nicht perfekt und wir sind es nicht, warum sollte es unsere Software sein? Perfekte Software ist schlichtweg unmöglich. Sie ist unmöglich, weil sich die Welt rund um die Software ständig ändert. So ändern sich die Anforderungen, im Idealfall werden sie konkreter und damit für alle besser. Wir wissen besser, was unser Kunde will und der Kunde erhält eher das, was er braucht. So ändern sich die Tools mit denen wir arbeiten. Werden sie besser, so verbessert sich unser Stil Software zu entwickeln - oder wirft uns um Jahre zurück. So ändern auch wir uns. Mit jedem Projekt wächst unser Wissen und Können, auch wenn wir uns ehrlicher Weise auch bei ählichen Fehlern immer wieder selber stellen. Das war wir gestern geschrieben haben, ist uns Wissen, Können und Vermögen von gestern und das kann das Beste gewesen sein, was wir zu diesem Zeitpunkt leisten konnten.
Allerdings ist das alles kein Grund schlechte Software zu akzeptieren. Oder möchten Sie schlechte Software benutzen. Jeder von uns erwartet, daß der Geldautomat zu jeder Tageszeit funktioniert und nicht irgendwie, sondern richtig. Und freut sich, wenn das zu übernehmende Projekt gut geführt und die Sofware sauber implementiert ist.

Vielmehr sollten wir uns umso mehr bemühen gute Software mit perfekten Code zu entwicklen. Wie schon weiter oben geschrieben ist das Ziel nicht erreichbar, doch wenn wir es uns als Ziel setzen werden die Ergebnisse weit besser sein, als wenn wir uns von vornherein nur mit Mittelmäßigkeit begnügen. Denn sobald wir dies verinnerlicht haben, werden wir uns mit noch weniger zufrieden geben.