Für die einen revolutionär, für andere Kinderkram – an RAD-Werkzeugen scheiden sich die Geister. Das Linux-Magazin hat Verfechter beider Standpunkte um Begründungen gebeten.

Kann ein ambitioniertes Programmierwerkzeug Laien zu Entwicklern befördern, indem es ihnen das Kodieren abnimmt? Oder macht es sie in Wahrheit damit nur zu Sklaven einer unverstandenen Technik? Klickt man sich rascher durch ein paar Dialoge, als man deren Optionen tippen könnte, oder ist es umgekehrt? Vertreter des Rapid Application Development meinen, mit einer schnellen Lösung komme der Programmierer oft weiter als mit einer perfekten. Gegner argumentieren, in Softwareprojekten ginge die Zeit ohnehin nicht beim Entwickeln im engeren Sinn verloren.

Für beide Seiten lassen sich gute Argumente finden, das Linux-Magazin hat zwei seiner Autoren gebeten, sie zu erläutern. Der erfahrene Java-Profi Bernhard Bablok sieht eher skeptisch auf die vermeintlichen Vorzüge von RAD-Werkzeugen. Solide Handarbeit, meint er, ist in vielen Fällen effizienter.

Der Mathematiker, Autor und Dozent Ralph Steyer dagegen schildert die Vorzüge grafisch unterstützter Programmentwicklung. Für ihn überwiegen unterm Strich die Vorteile.

Pro

Im Prinzip braucht der Programmierer nicht mehr als einen Texteditor, in den er den Quelltext tippt. Eine so asketische Ausrüstung wäre außerdem billig, schlank und flink – denn jedes Betriebssystem liefert das nötige Werkzeug mit. Doch die meisten Programmautoren geben sich nicht mit der Minimalausstattung zufrieden und bevorzugen zumindest einen spezialisierten Editor, viele auch eine integrierte Entwicklungsumgebung (IDE) und manche darüber hinaus spezielle Tools für schnelles Prototyping oder visuelles Programmieren – die Grenzen sind jeweils fließend, von Stufe zu Stufe winkt Komfortgewinn.

So verlangt ein grafisches Programmiertool sehr viel weniger Tipparbeit und entbindet den Benutzer zusätzlich von dem Zwang, alle Befehle mit allen Parametern in exakter Schreibweise im Kopf zu behalten. Das hilft besonders Programmierern, die permanent zwischen verschiedenen Sprachen wechseln und daher Gefahr laufen, Ausdrücke zu verwechseln. Solchen Irrtümern, aber auch einfachen Tippfehlern beugt eine intelligente Arbeitsumgebung wirksam vor.

Routinejobs für Assistenten

Programme schreiben heißt sich wiederholen: Bestimmte Standardaktionen müssen immer wieder kodiert werden – etwa das Erzeugen einer grafischen Benutzeroberfläche oder der Zugriff auf Datenbanken nebst Darstellung der Abfrageergebnisse. Warum soll ein Programmierer im Grunde triviale Dinge immer wieder neu manuell eingeben, wenn ein Programm das besser, schneller und fehlerfreier kann? Es ist sinnvoller, wenn sich ein Programmierer auf die Dinge konzentriert, die ihm kein Code-Assistent abnehmen kann. Bei Standards sollten jedoch wenige Mausklicks und ein paar Eingaben in Assistenten genügen, aus denen der Rechner selbstständig das Grundgerüst für ein umfangreiches Programm zimmert.

Unterm Strich mehr Licht als Schatten

Natürlich birgt der Einsatz von RAD-Tools auch potenzielle Probleme, etwa durch die Abhängigkeit des Code vom Werkzeug. Wägt man die Vor- und Nachteile ab, überwiegen aus meiner Sicht aber die Vorteile massiv. Allerdings sollte ein Programmierer im Prinzip auch ohne diese Tools auskommen – gerade dann wird er sie mit Gewinn verwenden.

Mit dem Blick des Praktikers und erfahrenen Programmierers hat Bernhard Bablok eines der getesteten RAD-Tools begutachtet und sich Gedanken über diese Klasse von Werkzeugen gemacht.

Kontra

Alle RAD-Tools versprechen viel: einfache Anwendungsentwicklung, kürzere Entwicklungszeiten und sinkende Kosten. Die Philosophie ist dabei immer gleich: Auf herkömmliche Weise Code schreiben gilt als langsam und ineffizient. Deshalb möchten viele dies am liebsten dem Rechner selbst überlassen, dem sie über eine grafische Oberfläche nur ein paar Vorgaben machen. Ob diese Rechnung für einen Profi aufgeht, ist sehr zweifelhaft.

Ein Beispiel für die Denkweise des RAD (Rapid Application Development) ist der Eva/3 Application Builder (siehe den entsprechenden Beitrag). Im sehr gut gemachten Tutorial ist “klicken” das häufigste Wort. Und in der Dokumentation ist wörtlich zu lesen: “Dies erlaubt den Einsatz aktueller IT-Erkenntnisse, ohne dass sich der Anwender mit diesen auseinandersetzen muss.”

Denken lassen?

Doch genau damit fangen die Probleme aller RAD-Tools an. Natürlich gibt es viele Entwickler, die mit zwei Fingern tippen. Für sie mag es kein Problem sein, immer wieder abwechselnd rechts und links zu klicken und zwischendurch das Mausrad zu bedienen, um dann drei Buchstaben einzugeben. Aber für die Zehnfinger-Schreiber unter den Programmierern ist der ständige Griff zur Maus wenig effizient.

Die mangelnde Auseinandersetzung mit aktuellen IT-Erkenntnissen bedeutet nur, dass der Nutzer einer RAD-Umgebung letztlich seinen eigenen Code nicht mehr versteht und nur noch die Oberfläche des Tools bedienen kann.

Schubumkehr

Lässt sich die Schreibtechnik noch unter die Geschmacksfragen rechnen, sind die vermeintlichen Vorteile auf anderen Gebieten objektiver zu beurteilen. Beispielsweise beim Anlegen von Datenbanktabellen: Mit einem klassischen Texteditor sind DDL-Statements (Data Definition Language) schnell getippt und ebenso schnell per Cut&Paste vervielfältigt. Im GUI eines RAD-Tools muss man den Namen der Spalte eingeben, dann eine Combo-Box selektieren, dann mit der Maus bis zum Eintrag für den gewünschten Datentyp scrollen, dann in das Längenfeld klicken und dort schließlich die Länge eintragen. Der ständige Wechsel zwischen Maus und Tastatur nervt schnell und ist kontraproduktiv. So ist es unmöglich, schneller zu sein als mit einem Editor.

Bei einem wirklich professionellen Entwicklungsablauf entwirft man seine Datenmodelle mittels Entity-Relationship-Tools (ER-Tool). Hier spielt Schnelligkeit weniger eine Rolle als die Visualisierung, ist doch das Datenmodell die entscheidende Grundlage für die gesamte Applikation. Entsprechend intensiv sind die Diskussionen zwischen den Entwicklern. Ist dann das Datenmodell fertig abgestimmt, werden die DDL-Statements, aus denen die Datenbank generiert wird, einfach aus dem ER-Tool exportiert. Dank dieser Standardfunktion entfällt später das manuelle Erstellen von Datenbankobjekten ohnehin.

Sinnvoll: Berichtsbaukasten

Ähnlich sieht es mit Dialogen und Panels aus. Alle möglichen Attribute wie Hintergrundfarben, Fonts, Größen, Constraints und so weiter erreicht man nur über vielfache Klicks. Lediglich das Layout lässt sich leichter über einen grafischen Designer erstellen. Aber auch nicht notwendigerweise schneller. Eigene Erfahrungen mit Java-Anfängern (Anfängern in dieser Sprache, nicht Programmieranfängern) zeigen: Wer das Prinzip des Grid-Bag-Layouts verstanden und ein Beispiel vorliegen hat, kommt auch ohne grafischen Designer schnell zu vorzeigbaren Ergebnissen.

Wirklich nützlich ist der grafische Ansatz zum Beispiel für den Entwurf von Berichten, weil hier auch ein geschulter Java-Entwickler, der vielleicht JFreereport verwendet, nicht ohne weiteres am Code erkennen kann, wie das Ergebnis aussehen wird.

Wer ein RAD-Tool verwendet, bindet sich daran und kann später nicht ohne weiteres zu einem anderen Werkzeug wechseln – der zwischenzeitlich produzierte Code ist keineswegs neutral.

Drum prüfe, wer sichewig bindet

Damit verbunden ist ein weiterer Nachteil: Sollte das Laufzeitsystem des Entwicklungswerkzeugs einen Fehler enthalten, ist das Warten auf ein Patch des Herstellers unvermeidlich. Meine persönliche Erfahrung lehrt, dass kleine Hersteller hier oft professionell und schnell reagieren, während große Anbieter nicht selten bis zur nächsten Release warten. Aufwändige Workarounds sind zwangsläufig die Folge.

Ob ein Entwicklerteam, das ein RAD-Tool virtuos beherrscht, schneller ist als ein vergleichbares Team, das entsprechende Erfahrung (und damit auch ein gewachsenes Applikationsframework) mitbringt, bleibt für mich doch sehr zweifelhaft.

Für die gesamte Projektlaufzeit spielt die reine Kodierungszeit sowieso nur eine untergeordnete Rolle. Selbst wenn die RAD-Tools alle Versprechungen wahr machen würden, wären mit ihnen nie die Verzögerungen hereinzuholen, die in Softwareprojekten üblicherweise durch die Anforderungsanalyse und durch Abstimmungen mit dem Auftraggeber entstehen. (jcb)