Code-Generierung hat einen Vorteil, der oft übersehen wird: Man kann den generierten Code patchen, sprich Fehler darin beheben, ohne die Generator-Software anzufassen.
Ich arbeite derzeit an einem Projekt, in dem aus XML-Dateien HTML-Dateien samt zugehörigem JavaScript generiert werden. Die XML-Dateien spezifizieren ein Dialogsystem, die per JavaScript gesteuerten HTML-Seiten führen das Dialogsystem aus.
Nun ist es so, dass ich die Generatorsoftware nicht geschrieben habe. Zwar habe ich Zugriff auf den Quellcode, doch möchte ich am Code vorerst nichts ändern. Die Generatorsoftware hat sich in einem vorangegangenen Projekt bewährt, arbeitet zuverlässig und nimmt an den XML-Spezifikationen zahllose Konsistenzüberprüfungen vor -- und das ist Gold wert. Hier heißt es Finger weg, solange es geht, getreu der Devise: Never touch a running/working system.
Im jetzigen Projekt wird jedoch anhand neuer XML-Spezifikationen deutlich, dass der Generator HTML-Code erzeugt, der Missverständnisse in den Anforderungen an das System offenbart. Der Generator erzeugt also Code, der nicht "passt". Und das, obwohl das System funktional sehr gut spezifiziert ist. That's life.
Es ist nicht ohne Risiken, die Generatorsoftware direkt anzupassen: Ich baue mir möglicherweise neue Fehler ein, breche bestehende Funktionalitäten und riskiere Inkompatibilitäten zum generierten Code aus der ersten Projektphase.
Eine Alternative ist, sich Programme zu schreiben, die die Probleme im generierten Code beheben (patchen). Diese Strategie lässt die Generatorsoftware unangetastet und intakt. Stattdessen beschränkt und fokussiert sich alle Aufmerksamkeit auf das Endprodukt, auf den durch die Patch-Programme modifizierten generierten Code. Genau darauf sollen sich auch die Testing-Energien konzentrieren, nicht auf die Generator-Software. Da die Komplexität der Patch-Programme -- im Vergleich zur Generatorsoftware -- gering und überschaubar ist, ist auch mit weniger Programmierfehlern zu rechnen. Zuguterletzt sind die Patch-Programme hervorragende Spezifikationen für die Änderungen, die in einem späteren Schritt an der Generatorsoftware vorgenommen werden können.
Patching ist nicht nur eine simple Technik der Fehlerkorrektur, sondern es kann eine sehr gezielte Engineering-Aktivität sein, die hilft, bessere Software zu entwickeln.
Ich arbeite derzeit an einem Projekt, in dem aus XML-Dateien HTML-Dateien samt zugehörigem JavaScript generiert werden. Die XML-Dateien spezifizieren ein Dialogsystem, die per JavaScript gesteuerten HTML-Seiten führen das Dialogsystem aus.
Nun ist es so, dass ich die Generatorsoftware nicht geschrieben habe. Zwar habe ich Zugriff auf den Quellcode, doch möchte ich am Code vorerst nichts ändern. Die Generatorsoftware hat sich in einem vorangegangenen Projekt bewährt, arbeitet zuverlässig und nimmt an den XML-Spezifikationen zahllose Konsistenzüberprüfungen vor -- und das ist Gold wert. Hier heißt es Finger weg, solange es geht, getreu der Devise: Never touch a running/working system.
Im jetzigen Projekt wird jedoch anhand neuer XML-Spezifikationen deutlich, dass der Generator HTML-Code erzeugt, der Missverständnisse in den Anforderungen an das System offenbart. Der Generator erzeugt also Code, der nicht "passt". Und das, obwohl das System funktional sehr gut spezifiziert ist. That's life.
Es ist nicht ohne Risiken, die Generatorsoftware direkt anzupassen: Ich baue mir möglicherweise neue Fehler ein, breche bestehende Funktionalitäten und riskiere Inkompatibilitäten zum generierten Code aus der ersten Projektphase.
Eine Alternative ist, sich Programme zu schreiben, die die Probleme im generierten Code beheben (patchen). Diese Strategie lässt die Generatorsoftware unangetastet und intakt. Stattdessen beschränkt und fokussiert sich alle Aufmerksamkeit auf das Endprodukt, auf den durch die Patch-Programme modifizierten generierten Code. Genau darauf sollen sich auch die Testing-Energien konzentrieren, nicht auf die Generator-Software. Da die Komplexität der Patch-Programme -- im Vergleich zur Generatorsoftware -- gering und überschaubar ist, ist auch mit weniger Programmierfehlern zu rechnen. Zuguterletzt sind die Patch-Programme hervorragende Spezifikationen für die Änderungen, die in einem späteren Schritt an der Generatorsoftware vorgenommen werden können.
Patching ist nicht nur eine simple Technik der Fehlerkorrektur, sondern es kann eine sehr gezielte Engineering-Aktivität sein, die hilft, bessere Software zu entwickeln.