Being a Java Enterprise Developer

No Milk today

Am Morgen würde das Prädikat „The Breakfast-driven Company“ bestens zu unserer Softwarebastelstube passen. Ich hole mir noch schnell einen Kaffee und stehe dabei wie immer mit zitterndem Finger am Kaffeekannenabzug. Eine ungeschriebene Firmenregel besagt nämlich: Derjenige, der die Kanne leert, muss umgehend für neuen Kaffee sorgen. Ich habe allerdings Glück. Dafür höre ich den Kollegen nach mir beim Weggehen noch leise fluchen. Freitags dürfen wir uns immer über Weißwürste freuen. Gäbe es noch eine Maß Bier dazu, könnte man fast glauben, dass sich hier ein paar Bayern nach Preußen verirrt haben. Beim Frühstück ergeben sich oftmals sehr philosophische Gespräche. Heute wird einmal mehr über das Lieblingsthema der Informatiker diskutiert, und zwar welches Computersystem denn das beste sei. Die Apfelfans kämpfen verbissen – Gott sei Dank nur verbal – gegen die PC-Freunde. Ich mische auf beiden Seiten mit und schütte, wie es sich für einen guten Kollegen gehört, immer wieder Öl ins Feuer.

Viele Jahre war die Geschichte unseres mittlerweile ausgeschiedenen Visionärs das zentrale Frühstücksthema: Sein Wasserzähler in der Kleingartenanlage hatte sich rückwärts gedreht und daraufhin wurde munter hin- und hergeklagt, wurden mehrere Sachverständige um ihre Expertise gebeten und selbst Bürgermeister Klaus Wowereit durfte sich über einen Anruf in dieser Sache freuen. Einem Land, in dem eine solche Sache über viele Jahre unzählige Personen beschäftigt, kann es jedenfalls wirtschaftlich noch nicht schlecht gehen.

Wild Wild West

Als Brancheneinsteiger glaubt man, dass ein Softwareentwickler die meiste Zeit mit dem Erstellen neuer Systeme auf Basis der neuesten Technologien beschäftigt ist. Diese Traumvorstellung weicht aber bald der Realität. In Wahrheit geht nämlich ein Großteil der Arbeitszeit für die Pflege bestehender Anwendungen drauf. Da kaum ein Kunde bereit ist, für Technologieupgrades ohne funktionalen Zugewinn zu bezahlen, wird der Programmierer bei der Anpassung und Erweiterung solcher Applikationen immer wieder mit Java-Technologien konfrontiert, mit denen er lieber nichts mehr zu tun hätte. Angesichts der großen Zahl an Webframeworks, die bis dato in unserem Unternehmen zum Einsatz gelangten, könnten wir locker ein virtuelles Museum eröffnen. Und so manch prähistorisch anmutender Artgenosse lässt sich sogar auf einem unserer Firmenserver noch in freier Wildbahn beobachten.

Des Weiteren gibt es wohl keine Branche, in der derart viele Prototypen als produktive Systeme zum Einsatz gelangen. Lernte ich an der Universität noch, dass der Prototyp weggeschmissen werden sollte, nachdem er seinen Zweck erfüllt hat, so sieht die industrielle Wirklichkeit doch ein wenig anders aus. Auf Anweisung des vorgesetzten Managers werden zum quick and dirty implementierten Prototyp oftmals nur mehr die fehlenden Funktionalitäten dazugebastelt, und schon gilt das System als fertig. Dass man dadurch gleich von Beginn an die Chance auf ein qualitativ hochwertiges Stück Software verwirkt, wird leider nicht berücksichtigt.

Meine heutige Vormittagsbeschäftigung ist die Behebung eines Bugs in unserer webbasierten Zeiterfassung, eines meiner ersten Projekte. Webframeworks gab es damals noch keine und so realisierte ich die Applikation, wie es seinerzeit eben üblich war: ein paar JSPs hier, ein paar Servlets da und dazu noch ein paar Klassen, die den Rest erledigen. Was die Struktur betrifft, würde ich das Ganze nach wie vor als gut gelungen bezeichnen, wäre da nicht eine Sache passiert: Über die Jahre haben sich verschiedene Praktikanten an dieser Software austoben dürfen und dabei den seinerzeit gut strukturierten Code Schritt für Schritt in Spaghetti verwandelt. Ein kurzer Blick in die zugehörige technische Spezifikation hätte gereicht, um meine Ideen nachvollziehen zu können, aber das Lesen solcher Dokumente ist bekanntlich ziemlich uncool. So versuche ich zu retten, was zu retten ist. Zwischendurch begegnen mir Source-Teile, die es problemlos zur firmenweiten Codestelle des Monats schaffen würden:

if (parameter == null || parameter.length() == 0) {
parameter = null;
}

Keine Frage, dieser Quellcode funktioniert einwandfrei, jedoch ließe sich das eleganter formulieren. Noch dazu hätte es Sinn gemacht, die Überprüfung in eine statische Methode auszulagern und diese bei Bedarf aufzurufen, anstatt hunderte Male ein und denselben redundanten Code anzuschreiben. Vor dem Einspielen der überarbeiteten Version entdecke ich noch ein weiteres Codehighlight, dem ich sogleich zu Leibe rücke:

if (mitarbeiter.getGruppe() == Gruppe.ADMIN) {
  // HIER WURDE JEDE MENGE CODE AUSKOMMENTIERT.
  addProjektAuswahl();
}
else {
  addProjektAuswahl();
}
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.