Kategorien
Themen

Generatoren, Segen oder Fluch?

Zuerst, ich mag Generatoren, ein Compiler ist auch ein Generator, der aus etwas, was ich verstehe, etwas generiert, was der Computer versteht.

Andere Generatoren nehmen dem Programmierer viel Arbeit ab, zum Beispiel das Generieren der Getter und Setter in Eclipse. Die Getter und Setter werden nur einmal generiert und danach modifiziert!

Als Programmierer verbringt man viel Arbeitszeit mit dem Debuggen von Programmen. Natürlich nicht den selbst erstellten, die sind ja fehlerfrei, oder?

Vor einigen Jahren durfte ich eine Unschärfe in einem 3270 Dialog-Programm suchen. Das Programm war mit einem Generator „Telon“ erzeugt worden und zeigte laut Bug-Meldung manchmal den letzten Datensatz in einer Liste nicht an. Das Problem war anhand des Modells, das der Generator als Eingabe verwendete, nicht zu erkennen. Der Kollege, der einige Zeit vorher das Programm erstellt hatte, war auch nicht mehr greifbar. Also habe ich mich zwei Tag durch die vielen tausend Zeilen generierten, sehr schlecht lesbare, die Technologie des Herstellers verschleiernden Code mit dem Debugger gewühlt. Das Problem war eigentlich trivial, am Ende der CURSOR Verarbeitung von zwei mit UNION verbundenen SELECT Anweisungen wurde der SQL-Code so interpretiert, dass der letzte Satz nicht in die anzuzeigende Liste übernommen wurde. Die Prüfung des SQL Codes und ggf. das Setzen des richtigen SQL Codes, damit anschliessend der generierte Code auch den letzten Satz übernahm, war schnell im Modell eingebaut, das Programm neu generiert und kompiliert. Aber die zwei Tage „auf den Bildschirm starren“ war sehr anstrengend. Hätte ich auf Level des Modells debuggen können, hätte ich das Problem wohl in wenigen Minuten gefunden. 

In meiner Anfangszeit, so vor dreizig Jahren, habe ich auch einen Generator (für dBase, unter MS-DOS eine weit verbreitete „Datenbank“ mit Programmiersprache) geschrieben. Damit hatte ich dann einige Anwendungen generiert und im Einsatz. Aber es gab den ein oder anderen Bug im generierten Code, der natürlich nicht beim Testen des Generators und meiner ersten (Test-) Anwendung auffiel, sondern später, als etliche Programme mit dem Generator erzeugt waren. Das Finden des Fehlers dauerte von Minuten bis zu einer halben Stunde, die Änderungen im Generator hatte ich 5 Minuten eingebaut, das Neugenerieren und Testen der Anwendungen brauchte dann so ein bis zwei Tage. 

Das musste doch besser gehen, sagte ich mir.
Aber leider nicht in dBase! Mit „Clipper“ (einen Compiler für dBase) konnte ich die Idee umsetzen. Ich baute einen Rahmen (Framework) und eine Anzahl an Library Funktionen. Die für die jeweilige Anwendung benötigte Funktionalität baute ich in Prozeduren ein, die die Library Funktionen nutzten und die ich beim Framework anmeldete. Damit wurde nichts mehr generiert, sondern die Dinge, die bisher der Generator „schrieb“, waren jetzt „einfach da“. Bug gab es auch hier, aber nach dem Finden und Beseitigen musste nur noch der Linker laufen.

Beim Übersetzen der Library-Funktionen hatte ich meist mit Absicht die Debugger-Unterstützung ausgeschaltet, so konnte ich die Anwendung testen und wanderte nicht in die Tiefen der allgemeinen Funktionen.

Ich sehe seitdem Generatoren kritisch.
Einfache Dinge, siehe Getter und Setter, machen Sinn.

Generatoren für komplexe Dinge sind schneller erstellt wie ein entsprechendes Framework.

Aber das Debuggen muss auf Ebene des Generator Inputs, also des Modells, erfolgen können. 
Und hier werden Generatoren, die einfach nur Sourcen in einer Zielsprache (COBOL, JAVA, …) erstellen, scheitern. 
Das Debuggen wird in der Zielsprache stattfinden müssen, und der Debugger kann nicht die „allgemeinen“ Teile der generierten Sourcen ausblenden und nur die für die zu testende Anwendung speziellen Teile anzeigen.
Der Entwickler hat „in seinem Kopf“ ständig den Generator am Laufen, er muss das Modell, in dem sein Programm erstellt wurde, ja ständig mit der Source im Debugger, also den aus dem Modell generierten Code, abgleichen.

Fehlerbeseitigung am Generator bedeutet immer, aller Programme neu zu generieren und zu testen.

Es soll übrigens Programmierer geben, die in generierten Sourcen ändern. Wenn dieses vor dem Neugenerieren nicht auffällt, beginnen die Probleme erst.