Agile Softwareentwicklung mit Hibernate, Spring, Eclipse

24 Juni 2010 von Heiko Kommentieren »

Heute war ich in Karlsruhe in einem Workshop im Rahmen der Entwicklertage. Thema: „Durchstarten – Agile Softwareentwicklung mit Hibernate, Spring, Eclipse„. Ich habe diesen Workshop bewusst gewählt, da sie laut Beschreibung den Anspruch hat, agile Praktiken anhand dieser Technologien zu zeigen. Das hat sie auch voll erfüllt, keine Frage.
Allerdings sah ich mich auch in meiner Meinung bezgl. der „Geschwätzigkeit“ dieses Technologiestacks voll bestätigt. DRY ist anders. Es handelte sich um eine für einen Workshop vorbildhaft große Beispielapplikation, an der wir diverse agile Methoden praktizierten, also Einarbeitung in ein fremdes Projekt, Feautererweiterung im Sprint, Bugfixing von Legacy-Code usw.

Dabei fühlte ich mich bei der Entwicklung von weiteren Features jedoch öfters an eine typische ehemalige Situationen erinnert: Für die Aufgaben wurde eine Menge Code kopiert und leicht abgeändert, ohne im Detail zu wissen, was man da eigentlich macht, aber wenn es für die Modellklasse X so funktioniert, müsste es für die Modellklasse Y ja auch so gehen. Es ging dann auch (wenn man keine Copy+Paste+Abänder-Fehler machte), aber gut hat sich das ganz und gar nicht angefühlt, da man eben eine Menge Code manuell erstellt, der im Grunde nur von der einen zur nächsten Schicht delegiert: vom Frontend zum Service zum DAO zum Model. Dazu diverse Hilfsklassen um Spring und Hibernate einen Kontext zu geben und die Services nach außen per HTTP bekannt zu machen.

Aus meiner früheren Java-Erfahrung kenne ich das nur zu gut, in der Ruby-Welt habe ich so etwas noch nie gesehen.
Hier würde man sicherlich einiges, insb. den ganzen Delegationscode, so entwickeln, dass er zur Laufzeit weiterleitet. Dort, wo nicht 1:1 weiterdelgiert wird, kann man mit manuellen Methoden eingreifen, ansonsten läuft alles generisch. In Java könnte man es sicherlich auch gefälliger hinbekommen, (mit Reflection), aber es ist dort kein guter Style. In dynamischen Sprachen dagegen ist diese Art von dynmischem Code jedoch alltäglich.
Durch diesen duplizierten, leicht veränderten Code kann ich gut die Versuchung verstehen, hier mit MDSD anzusetzen. Vor einige Jahren habe ich das auch intensiv gemacht. Damals hatten wir auch intensiv über dynamische Aufrufe vs. Codegenerierung diskutiert, aber wir fanden es nicht wirklich praktikabel.
Seit ich dynamische Sprachen täglich im Einsatz habe, frage ich mich immer mehr, warum das in Java so sein muss. Als Antwort fällt mir immer und immer wieder die Notwendigkeit zur Typisierung ein…
Was meint ihr dazu?

Schreibe einen Kommentar