Agile Software-Entwicklungsmethoden, insesondere Scrum, haben sich inzwischen als ernsthafte Alternative etabliert, es gibt eine große Gruppe zufriedener Menschen, die sie täglich praktizieren.
Es gibt viele Mitteln und Wege, die für die tägliche Umsetzung dieser Methoden genutzt werden. Das Team praktiziert diese Rituale (Sprint, Daily Scrum, Retrospektiven usw.) gerne, denn sie passen sehr gut zur agilen Denkweise. Meist setzen sich die Team-Mitglieder nach dem Daily Scrum an die Tastatur und den Compiler, und schon ist die Agilität wieder verflogen…
Mit LessCode möchten wir das Bewusstsein schaffen, dass es nach wie vor eine große Diskrepanz gibt, zwischen den Werkzeugen der agilen Methoden und den Werkzeugen, mit denen das Team die meiste Zeit seiner Arbeit zu tun hat: Den Compilern, Lautzeitumgebungen, Tools und Frameworks. Diese sind in unseren Augen oftmals nicht wirklich agil (sorry für die Überstrapazierung dieses Wortes) und daher ist es Wert, deren Einsatz zu überdenken.
Bei den Entwicklungsmethoden ist der Sprung geschafft: Weg vom 200-seitigen Pflichtenheften, hin zu überschaubaren Userstories; weg vom Wasserfall, hin zu kurzen Iterationen. Aber die meiste Arbeitszeit hat das Team immer noch mit echten Monstern zu kämpfen:
- geschwätzigen Programmiersprachen,
- aufwendigen ORM-Frameworks,
- endlosen Zeilen XML-Konfiguration,
- komplizierte generische oder generierten Code-Schichten, die ohne externe Berater kaum noch jemand versteht
- vielleicht sogar mit extrateuren Applikationsservern von dreibuchstabigen Firmen
Muss das wirklich so sein?
Mit LessCode wollen wir zeigen, dass es alternative Ansätze gibt:
- dynamische untypisierte Sprachen – Java ist kein goldener Hammer
- agile Frameworks
- Konvention statt Konfiguration
- DRY (Don’t Repeat Yourself)
- Frameworks, von Opensource-Communities getrieben
Deshalb raten wir dazu, alternativen Ansätzen eine Chance zu geben. Dazu gehört Mut, genauso wie das erste Befassen mit z.B. Scrum ebenfalls Mut und Offenheit für Neues erforderte.
Als konkrete Umgebungen können wir Ruby on Rails oder das Grails Framework empfehlen, da wir damit unsere Erfahrungen gemacht haben und sie guten Gewissens als „reif für die Produktionsumgebung“ bezeichnen können.
Die Produkte sind sich nicht nur oberflächlich recht ähnlich. Grails übernimmt so gut es geht die Entwicklungsphilosophien von Rails und implementiert sie auf Basis von Java-Frameworks (Spring und Hibernate). Meinem persönlichen Gefühl nach spürt man bei Ruby on Rails nach deutlicher den „Spirit“ – allein schon dadurch, dass die Rubyisten aus einer sehr agilen Ecke kommen, während man Java eben doch anmerkt, dass dahinter Multimilliardenkonzerne stecken, was das „Agilsein“ der Sprache oftmals schon im Keim erstickt.
Beide Systeme laufen in der Java-VM, so dass man auf einem Produktionsserver letztlich auch nur eine .war-Datei zur Ausführung bringt. Und natürlich lassen sich mit beiden Systemen in aller Regel vorhandene Java-Bibliotheken problemlos einbinden, so dass auch Legacy-Code weiter genutzt werden kann.
Freuen Sie sich auch weitere Artikel zum Thema hier.
