Low-Code in Git

Low-Code-Plattformen lösen ein reales Problem: Fachanwendungen schneller bauen, ohne bei jedem Formular von null anzufangen. Das Problem, das sie dafür eintauschen, wird selten erwähnt — Versionskontrolle.

Das Kernproblem

Servoy speichert UI, Datenmodell und einen Teil der Logik in einer Mischung aus JSON- und proprietären Dateien pro Formular. Technisch ist das textbasiert und damit git-fähig. Praktisch ist ein Diff aus zwei Formular-Versionen oft eine Wand aus umsortierten Properties, bei der die eine tatsächliche inhaltliche Änderung im Rauschen untergeht.

Das eigentliche Ziel ist nicht “irgendwie in Git bekommen” — das geht ohnehin. Das Ziel ist ein Diff, den ein zweiter Entwickler im Code-Review tatsächlich lesen kann, ohne die komplette Datei im Kopf neu zu rendern.

Was tatsächlich hilft

Ein paar Punkte, die den Unterschied machen:

• Deterministische Serialisierung. Property-Reihenfolge und Formatierung müssen bei jedem Speichern gleich sein — sonst ist jeder Diff ein Rauschen-Diff, auch ohne inhaltliche Änderung.
• Ein Element pro Zeile, wo möglich. Näher an “ein Objekt, eine Zeile” kommt man dem Ziel eines lesbaren textuellen Diffs.
• Pre-Commit-Normalisierung. Ein kleines Skript, das vor jedem Commit die Solution-Dateien in ein konsistentes Format bringt, erspart endlose Diskussionen über Formatierungs-Diffs im Review.
• Ownership pro Formular, nicht pro Solution. Kleinere, klar zugeordnete Änderungseinheiten reduzieren Merge-Konflikte in einer Low-Code-Umgebung erheblich.

Keine dieser Maßnahmen macht Servoy zu einem klassischen Code-Repository. Aber sie machen den Unterschied zwischen “Code-Review als Ritual” und “Code-Review, der tatsächlich Fehler findet”.