Regeneration-first‑Entwicklung für Apps, die sich sicher verändern

Warum Patches zu technischer Schuld werden

Patching passiert, wenn eine neue Anforderung auftaucht und du sie mit der kleinstmöglichen Änderung in die App quetschst. Es fühlt sich schnell an — weil es schnell ist. Das Problem ist: Jeder Patch ist eine lokale Lösung, und lokale Lösungen passen selten zur idealen Struktur der App.

Mit der Zeit häufen sich Patches. Die App läuft weiter, aber Code und Konfiguration fangen an, sich zu widersprechen: Die Datenbank sagt das eine, die UI impliziert etwas anderes und die echten Regeln liegen an drei verschiedenen Stellen. Diese Diskrepanz ist technische Schuld. Es ist nicht nur „schlechter Code“ — es ist die wachsende Kostenlast für die nächste Änderung.

Man erkennt es meist an folgenden Punkten:

• Die Logik verheddert sich, sodass eine kleine Regeländerung viele Bildschirme oder Endpunkte berührt.
• Felder werden dupliziert ("status", "ticket_status", "status_v2"), weil ein Umbenennen riskant erscheint.
• Die UI wird fragil, weil sie von bestimmten Datenformen oder Randfällen abhängt.
• Workarounds werden zu „temporären“ Flags, die nie verschwinden.
• Fixes brauchen Folgefixes, weil niemand sicher ist, was sonst noch kaputtgehen könnte.

Das Schlimme ist, wie schnell das Risiko wächst. Eine Änderung, die klein sein sollte (ein Freigabeschritt, eine Preisregel anpassen, eine Rolle aufsplitten), wird zu einem riskanten Release, weil man die Auswirkungen nicht vorhersagen kann. Tests werden geraten, Rollbacks schwerer, weil der Patch unerwartete Teile berührt hat.

Regeneration‑first‑Entwicklung ist eine direkte Antwort darauf. Ziel ist, die App so zu strukturieren, dass Änderungen vorhersehbar und umkehrbar sind und die Plattform sauberen Code regenerieren kann, ohne die Hacks von gestern mitzuschleppen.

Ein praktisches Ziel:

• Eine eindeutige Quelle der Wahrheit für Daten (keine doppelten „fast gleichen“ Felder).
• Regeln leben an einem Ort, nicht verstreut in UI und Endpunkten.
• Die UI konzentriert sich auf Darstellung und Eingabe, nicht auf Geschäftsentscheidungen.
• Änderungen passieren im Modell und in der Logik, dann regenerierst du, statt Outputs von Hand zu verändern.

Plattformen wie AppMaster unterstützen das, weil die App über Modelle und visuelle Logik definiert ist und die Plattform kompletten Quellcode regeneriert. Regeneration bleibt sauber, wenn du von Anfang an patchgetriebene Strukturen vermeidest.

Was Regeneration‑first‑Entwicklung bedeutet

Regeneration‑first‑Entwicklung behandelt deine App als Menge klarer Modelle, nicht als Haufen handbearbeiteten Codes. Du änderst die Modelle, regenerierst und erhältst eine frische, konsistente Version der App. Der Sinn ist, Änderungen auszuliefern, ohne dabei Hacks zu hinterlassen, die die nächste Änderung erschweren.

Im patch‑first‑Workflow wird eine kleine Bitte (ein neues Status‑Feld, ein neuer Freigabeschritt) dort eingebaut, wo es am schnellsten passt. Jemand passt einen API‑Handler an, aktualisiert einen Bildschirm, fügt irgendwo eine Sonderregel ein und gut ist. Die App funktioniert heute, aber die Logik ist verstreut. Nach ein paar Zyklen weiß niemand mehr genau, wo die echten Regeln liegen.

Bei Regeneration‑first bleibt die Quelle der Wahrheit in den Modellen:

• Datenmodell: Entitäten, Felder, Beziehungen, Constraints
• Geschäftslogik‑Modell: Regeln und Abläufe, die entscheiden, was passiert
• UI‑Modell: Bildschirme, Komponenten und ihre Datenbindung

Alles, was aus diesen Modellen generiert wird (API‑Endpunkte, Datenbankzugriff, Web‑ und Mobile‑Code), ist Ausgabe, nicht der Ort für schnelle Fixes.

In AppMaster kann diese Ausgabe Go für das Backend, Vue3 für die Web‑App und Kotlin oder SwiftUI für Mobile umfassen. Wenn Anforderungen sich ändern, aktualisierst du das Modell einmal und regenerierst, statt dieselbe Regel in vielen Dateien zu suchen.

So bleibt die App über alle Schichten hinweg konsistent, weil dieselben Definitionen jeden Teil antreiben. Wenn „Ticket Status“ verpflichtend wird, sollten Schema, Validierung, API und UI‑Bindings gleichzeitig aktualisiert werden. Ändert sich eine Freigaberegel, passt du den Prozess an, sodass jeder Endpunkt und Bildschirm dieselbe Logik widerspiegelt.

Die Denkweise ist einfach: Bearbeite das, was du meinst (Modelle), generiere das, was du brauchst (Code).

Baue ein Datenmodell, das sich entwickeln kann

Wenn Regeneration‑first funktionieren soll, fange mit dem Teil an, der sich am wenigsten ändern sollte: dem Datenmodell. Änderungsfreundliche Apps überstehen Feature‑Requests nicht, weil jeder Bildschirm perfekt ist, sondern weil die Kern‑Entitäten stabil und gut benannt sind.

Beginne mit den Nomen, die dein Geschäft in einem Jahr noch verwenden wird. Bei vielen Apps sind das User, Account, Team, Ticket, Order, Invoice, Product oder Message. Wenn diese klar sind, hat alles andere (Workflows, Berechtigungen, UI) eine solide Basis.

Benennung ist keine Kleinigkeit. Sie verhindert spätere Änderungen, die in verwirrende Migrationen und zerbrochene Logik münden. Wähle singuläre Namen für Entitäten, konsistente Feldnamen (created_at statt createdAt) und Typen, die zur Realität passen (Geld als Decimal, Zeitstempel mit vereinbarten Zeitzonenregeln). Kleine Inkonsistenzen verbreiten sich in Regeln, Filtern und Reports.

Plane Wachstum, ohne zu überdesignen. Du musst nicht jedes zukünftige Feld vorhersagen, aber du kannst gängige Änderungsarten sicherer gestalten:

• Bevorzuge Statusfelder, die neue Werte akzeptieren können, statt für jede Phase eine neue Tabelle anzulegen.
• Nutze optionale Felder für nicht immer vorhandene Daten (phone_number, external_id).
• Füge Audit‑Felder früh hinzu (created_at, updated_at, created_by), damit du später nichts nachrüsten musst.
• Halte „notes“ und „metadata“ getrennt von Kernfeldern, damit Experimente das Hauptmodell nicht verschmutzen.

Ein visueller Daten‑Designer hilft, weil du Beziehungen und Constraints siehst, bevor sie Code werden. Im Data Designer von AppMaster wird dein Schema auf PostgreSQL abgebildet, sodass du Tabellen, Felder und Verknüpfungen an einem Ort modellierst und bei Bedarf sauberen Quellcode regenerierst.

Beispiel: Ein Support‑Portal startet mit Tickets, die Accounts und Users zugeordnet sind. Später verlangt das Business Priorität, Kategorie und einen neuen Status „Waiting on Customer“. Wenn Tickets bereits ein Statusfeld und optionale Felder für Details haben, kannst du Werte und Felder hinzufügen, ohne die Datenbank neu zu entwerfen. Die regenerierte App hält Abfragen und APIs konsistent und verhindert einen Berg von Einzelpatches.

Das Ziel ist Lesbarkeit heute und Nachsicht morgen.

Mache Geschäftslogik modular und lesbar

Geschäftslogik ist der Ort, an dem Änderungen normalerweise Probleme verursachen. Ein schneller Fix, der „heute funktioniert“, kann morgen zu einem Netz aus Spezialfällen werden. Mit Regeneration‑first designst du Logik so, dass sie sauber regeneriert werden kann, ohne auf Patches zu bauen, die nur im Kopf einer Person Sinn ergeben.

Ein praktischer Ansatz ist, jeden Workflow als Sammlung kleiner Bausteine zu sehen. Jeder Block hat eine Aufgabe: Eingaben validieren, Preis berechnen, eine Route entscheiden, eine Nachricht senden, einen Datensatz aktualisieren. In AppMaster bildet das der Business Process Editor natürlich ab. Kleinere Prozesse sind leichter zu lesen, zu testen, wiederzuverwenden und zu ersetzen.

Denke in Eingaben und Ausgaben

Bevor du einen Block baust, notiere zwei Dinge: was er braucht und was er zurückgibt. Wenn du das nicht in einem Satz beschreiben kannst, macht der Block wahrscheinlich zu viel.

Gute Blöcke haben klare Grenzen. Sie nehmen explizite Eingaben (User‑Rolle, Ticket‑Status, Bestellsumme) und liefern explizite Ausgaben (genehmigt oder abgelehnt, Endpreis, nächster Schritt). Diese Klarheit macht Änderungen sicherer, weil du einen Block austauschen kannst, ohne raten zu müssen, was sonst noch betroffen ist.

Eine kurze Checkliste:

• Ein Zweck pro Block (Validierung, Berechnung oder Routing)
• Eingaben werden übergeben, nicht „irgendwo gefunden“
• Ausgaben werden zurückgegeben, nicht in Nebenwirkungen versteckt
• Namen beschreiben das Ergebnis (z. B. ValidateRefundRequest)
• Fehler werden konsistent behandelt

Versteckte Abhängigkeiten vermeiden

Versteckte Abhängigkeiten machen Logik fragil. Wenn ein Workflow auf globale Flags, stille Zustandsänderungen oder „diese Variable wurde irgendwo früher gesetzt“ angewiesen ist, können kleine Änderungen das Verhalten unerwartet verändern.

Gib den Zustand bewusst durch den Prozess weiter. Muss etwas gespeichert werden, leg es an einer offensichtlichen Stelle ab (Datenbankfeld) und lese es explizit. Vermeide „magisches“ Verhalten wie das Ändern eines Datensatzes in einem Schritt und das Hoffen, dass ein anderer Schritt das schon mitbekommt.

Mache Entscheidungsstellen sichtbar. Zum Beispiel könnte ein Support‑Portal nach „Ist dieses Ticket VIP?“ und „Ist es außerhalb der Geschäftszeiten?“ verzweigen. Wenn diese Verzweigungen klar und beschriftet sind, ist eine spätere Änderung wie „VIP‑Regeln ändern sich am Wochenende“ eine schnelle Anpassung statt eines riskanten Umbaus.

UI‑Belange von Regeln und Daten trennen

Eine änderungsfreundliche App lässt sich am leichtesten regenerieren, wenn die UI „dumm“ bleibt. Bildschirme sollten Eingaben sammeln, Zustände anzeigen und den Nutzer führen. Wenn Geschäftsentscheidungen in Buttons, Validierungen und einmaliger Bildschirmlogik versteckt sind, führt jede neue Anforderung zu einem Patch.

Behandle die UI als dünne Schicht über gemeinsamen Regeln und Daten. Dann kann die Plattform die Darstellung sauber neu bauen, ohne Entscheidungen an zehn Stellen neu implementieren zu müssen.

Wo die UI endet und Geschäftsregeln beginnen

Eine praktische Trennung ist: UI sorgt für Klarheit; Geschäftslogik sorgt für Wahrheit. Die UI kann formatieren, beschriften und Nutzer unterstützen. Die Geschäftslogik entscheidet, was erlaubt ist und was als Nächstes passiert.

UI‑Aufgaben sind oft:

• Daten anzeigen und Benutzer‑Eingaben erfassen
• Formatierung (Datum, Währung, Telefonmasken)
• Basisprüfungen auf Pflichtfelder (leer vs. nicht leer)
• Fehler, die von der Logik zurückkommen, in verständlicher Sprache anzeigen
• Navigation und Layout

Geschäftsregeln sollten außerhalb des Bildschirms leben, z. B. in einem Workflow/Prozess: „Rückerstattung benötigt Managerfreigabe“, „VIP‑Kunden überspringen die Warteschlange“, „Ticket kann nicht ohne Lösungs‑Code geschlossen werden“. Halte diese Regeln an das Datenmodell gebunden, nicht an eine spezielle Seite.

Einmal designen, web und mobile wiederverwenden

Wenn du mehr als einen Client unterstützt (Web und native Mobile), führt Duplikation zu Drift. Wiederverwende gemeinsame Komponenten für Muster (Ticket‑Status‑Badge, Prioritäts‑Selector, Kundenkarte) und halte Verhalten konsistent, indem du die gleichen Daten und dieselben Regelergebnisse fütterst.

Du kannst z. B. Ticket‑Zustände im Data Designer modellieren, Zustandswechsel über einen einzelnen Business‑Prozess steuern und sowohl Web als auch Mobile diesen Prozess aufrufen und den zurückgegebenen Zustand rendern lassen. Wenn „Escalated“ zu „Urgent review“ wird, aktualisierst du es einmal und regenerierst, statt versteckte Bedingungen in jedem Screen zu suchen.

Ein guter Test: Wenn du einen Bildschirm entfernst und morgen neu baust, würde die App immer noch dieselben Regeln durchsetzen? Wenn ja, funktioniert die Trennung.

Schritt für Schritt: Struktur für saubere Regeneration

Regeneration‑first funktioniert am besten, wenn deine App in klare Teile zerlegt ist, die unabhängig voneinander geändert werden können. Denk modular statt in Bildschirmen.

Benenne die Kernmodule und halte sie separat im Kopf und in der Arbeit: Daten (Tabellen und Relationen), Prozesse (Logik), API (Endpunkte), Web‑UI und Mobile‑UI. Wenn sich eine Anforderung ändert, solltest du zeigen können, was sich ändert und was unangetastet bleibt.

Eine Build‑Reihenfolge, die änderungsfreundlich bleibt

Arbeite in kurzen Schleifen und halte jeden Schritt überschaubar:

1. Modelliere zuerst die Daten: Entitäten, Felder, Beziehungen, die zur Realität passen.
2. Füge wiederverwendbare Business‑Prozesse als lesbare Flows hinzu. Jeder Prozess sollte eine Aufgabe erledigen (Create Ticket, Assign Agent, Close Ticket).
3. Verbinde Prozesse mit API‑Endpunkten, wenn die Logik lesbar ist. Behandle Endpunkte als Hülle um deine Flows, nicht als Ort, um Regeln zu verstecken.
4. Baue UI‑Bildschirme um Nutzeraufgaben, nicht um Datenbanktabellen.
5. Regeneriere und teste nach jeder kleinen Änderung.

Kleines Beispiel: Anforderungen ändern, ohne chaotische Patches

Angenommen, du baust ein Support‑Portal in AppMaster. Die erste Version hat Tickets und Comments. Eine Woche später fordert das Business Priority und eine Regel: VIP‑Kunden starten immer mit High.

Mit modularer Struktur änderst du das Datenmodell (Priority hinzufügen), aktualisierst einen Business‑Prozess (Create Ticket setzt Priority basierend auf Kundentyp), regenerierst und überprüfst, dass dieselbe UI‑Aufgabe weiterhin funktioniert. Keine verstreuten Änderungen über viele Bildschirme.

Eine einfache Gewohnheit hilft: Nach jeder Regeneration führst du die Schlüssel‑Flows kurz von Anfang bis Ende aus (create, update, permission check), bevor du das nächste Feature anpackst.

Beispiel: Ein Support‑Portal, das sich fortlaufend ändert

Stell dir ein kleines Support‑Portal vor. Kunden loggen sich ein, sehen ihre Tickets, öffnen ein Ticket, um Details zu sehen, und fügen eine Antwort hinzu. Support‑Agenten sehen dieselben Tickets plus interne Notizen.

Ein Regeneration‑first‑Ansatz trennt drei Dinge: das Ticket‑Datenmodell, die Business‑Prozesse (wie Tickets sich bewegen) und die UI‑Bildschirme. Wenn diese Teile klar sind, kannst du eines ändern, ohne die anderen zu patchen.

Einfach starten, aber auf Veränderung ausrichten

Die erste Version kann minimal sein:

• Daten: Users, Tickets, Messages
• Prozesse: Create ticket, Reply, Assign to agent
• UI: Ticket‑Liste, Ticket‑Details, Neues Ticket‑Formular

In AppMaster bildet das sauber ein PostgreSQL‑basiertes Datenmodell (Data Designer), einen Drag‑and‑Drop‑Workflow für Regeln (Business Process Editor) und separate Web‑ und Mobile‑UI‑Builder ab.

Änderung 1: Priorität und SLA‑Daten hinzufügen

Das Produktteam wünscht Priority (Low, Normal, High) und ein SLA‑Fälligkeitsdatum. Mit Regeneration‑first fügst du Felder zum Ticket‑Modell hinzu und aktualisierst nur die Stellen, die diese Felder lesen oder schreiben: Der Create‑Ticket‑Prozess setzt eine Standard‑Priority, der Agenten‑Bildschirm zeigt das SLA‑Datum und die Listenansicht erhält einen Filter.

Die Plattform regeneriert Backend und API, sodass die neuen Felder zu erstklassigen Teilen des Codes werden.

Änderung 2: Freigabeschritt vor dem Schließen

Jetzt muss das Schließen eines Tickets für bestimmte Kunden eine Managerfreigabe haben. Anstatt Close‑Regeln über mehrere Bildschirme zu verteilen, fügst du einen klaren Zustand ins Modell (Open, Pending approval, Closed) und aktualisierst den Close‑Prozess:

• Agent fordert Schließen an
• System prüft, ob eine Freigabe nötig ist
• Manager genehmigt oder lehnt ab
• Ticket wird erst nach Genehmigung geschlossen

Da die Regel in einem Prozess lebt, zeigt die UI den aktuellen Status und die nächsten erlaubten Aktionen an.

Änderung 3: Mobile Push‑Benachrichtigungen

Nutzer wollen Push‑Benachrichtigungen bei Agenten‑Antworten. Vergrabe die Notification‑Logik nicht im UI‑Code. Pack sie in den „New message“‑Prozess: Wenn eine Antwort gespeichert wird, löse ein Notification‑Modul aus. Die Regeneration liefert aktualisierte native Apps, ohne dass Änderungen in manuelles Patchwork ausarten.

Häufige Fehler, die Regeneration‑first brechen

Regeneration‑first funktioniert nur, wenn deine App regenerierbar bleibt. Teams brechen das meist mit schnellen Fixes, die sich heute harmlos anfühlen, aber morgen Workarounds erzwingen.

1) Generierten Code editieren statt das Modell ändern

Generierte Teile manuell zu bearbeiten, die beim Regenerieren überschrieben werden, ist der schnellste Weg, saubere Regeneration zu verlieren. Wenn du eine Plattform nutzt, die echten Quellcode generiert (wie AppMaster für Backend, Web und Mobile), behandle das visuelle Projekt als Quelle der Wahrheit. Ändere Datenmodell, Business‑Prozess oder UI‑Builder, nicht den generierten Code.

Eine einfache Regel: Wenn du die Änderung nicht durch Regenerieren aus dem visuellen Projekt reproduzieren kannst, ist es keine sichere Änderung.

2) Die UI die Regeln entscheiden lassen

Wenn Bildschirme Geschäftsregeln kodieren („diese Schaltfläche zeigt nur für VIP‑Nutzer“, „dieses Formular berechnet Summen in der UI“), wird jeder neue Bildschirm zum Spezialfall. Du endest mit versteckter Logik, die schwer konsistent zu aktualisieren ist.

Halte Validierungen, Berechtigungen und Berechnungen in der Geschäftslogik (z. B. in einem Business‑Process) und lass die UI das Ergebnis anzeigen.

3) Ein Fantasy‑Datenmodell zu früh entwerfen

Over‑Modeling sieht so aus, als würdest du dutzende Felder, Status und Randfall‑Tabellen hinzufügen, bevor du tatsächliche Nutzung hast. Das macht Änderungen schmerzhaft, weil jedes Update zu viele Stellen berührt.

Starte mit dem, was du weißt, und erweitere in kleinen Schritten:

• Füge nur Felder hinzu, die du in einfachen Worten erklären kannst.
• Halte Statuswerte realistisch kurz (3–6, nicht 20).
• Ziehe es vor, später eine neue Tabelle hinzuzufügen, statt alles in eine riesige Tabelle zu stopfen.

4) Benennungskonventionen überspringen

Inkonsistente Namen schaffen verwirrende Modelle und Endpunkte: „Cust“, „Customer“ und „Client“ in einer App. Regeneration funktioniert weiterhin, aber Menschen machen bei Änderungen Fehler.

Wähle früh ein einfaches Muster (singuläre Tabellennamen, konsistente Verben für Aktionen) und bleib dabei.

5) Einen gigantischen Workflow bauen

Ein riesiger Workflow wirkt anfangs ordentlich, wird aber schwer sicher zu ändern. Zerlege Logik in kleine Prozesse mit klaren Ein‑ und Ausgaben. In einem Support‑Portal: Trenne „Create ticket“, „Assign agent“ und „Send notification“, damit du einen Schritt ändern kannst, ohne den Rest zu riskieren.

Schnellchecks vor Regeneration und Deployment

Regeneration‑first fühlt sich nur sicher an, wenn du eine Routine hast, die gängige „stille Brüche“ abfängt. Vor dem Regenerieren mach einen kurzen Durchgang, der deiner App‑Struktur folgt: Daten, Logik, UI und APIs.

Eine schnelle Checkliste:

• Daten: Entitäten und Felder entsprechen den Anforderungen, Namen sind konsistent und du hast keine zwei Felder mit gleicher Bedeutung.
• Logik: Jeder Workflow hat klare Eingaben, klare Ausgaben und vorhersehbare Fehlerpfade.
• UI: Bildschirme verwenden gemeinsame Komponenten und hardcodieren keine Regeln.
• APIs: Endpunkte bilden Workflows konsistent ab. Du kannst beantworten: „Welcher Workflow treibt diesen Endpunkt an?“ ohne zu suchen.
• Release: Du hast ein kleines, wiederholbares Testszenario, nicht „herumklicken, bis es passt“.

Behalte eine einzige Quelle der Wahrheit für Regeln. Wenn Ticket‑Priority von Kundentier abhängt, definiere das in einem Workflow und lasse sowohl API als auch UI das gleiche Ergebnis anzeigen.

Ein 10‑Minuten Testskript, das reale Nutzung abbildet, reicht meist aus:

• Erstelle einen neuen Datensatz nur mit Pflichtfeldern.
• Starte den Hauptworkflow und bestätige die erwartete Statusänderung.
• Probiere einen bekannten Fehlerfall (fehlende Berechtigung oder fehlende Pflichtdaten).
• Öffne wichtige Bildschirme auf Web und Mobile und bestätige, dass dieselbe Regel gleich dargestellt wird.
• Rufe ein oder zwei Kernendpunkte auf und vergleiche die Antworten mit dem, was die UI zeigt.

Wenn etwas fehlschlägt, behebe zuerst die Struktur (Daten, Workflow, gemeinsame UI) und regeneriere erneut.

Nächste Schritte: Diese Vorgehensweise bei deiner nächsten Änderung anwenden

Wähle zunächst einen Bereich mit kleinem Umfang. Wenn vergangene Änderungen schmerzhaft waren, fang bei dem Teil an, der die meiste Nacharbeit verursacht hat: dem Datenmodell, einem verhedderten Logikteil oder einem Bildschirm, der ständig „nur eine Anpassung mehr“ braucht.

Behandle die nächste Änderung wie eine Übung: anpassen, regenerieren, verifizieren, ausliefern. Ziel ist, dass Updates routinemäßig und nicht risikoreich werden.

Eine einfache Schleife zum Wiederholen:

• Mach eine kleine Änderung (ein Feld, eine Regel oder ein Bildschirmverhalten).
• Regeneriere, damit der Code konsistent bleibt.
• Führe einen schnellen Smoke‑Test durch (Happy Path + einen Randfall).
• Deploye zuerst in einer sicheren Umgebung (Staging oder Test‑Workspace).
• Liefere aus und notiere, was du gelernt hast.

Halte ein kurzes Changelog, das Entscheidungen erklärt, nicht nur Änderungen. Zum Beispiel: „Wir speichern Ticket‑Priority als Enum statt als Freitext, damit Reports nicht brechen, wenn Labels sich ändern.“ Zwei Zeilen wie diese sparen später Stunden.

Wenn du das ohne manuelle Nachbearbeitung des generierten Outputs üben willst, baue ein kleines, abgegrenztes Modul in AppMaster (z. B. ein Ticket‑Formular, eine Admin‑Liste oder einen einfachen Freigabeschritt), regeneriere nach jeder Änderung und achte darauf, wie viel leichter sich die App entwickelt, wenn das Modell die Quelle der Wahrheit bleibt. Wenn du Tools evaluierst, ist appmaster.io ein einfacher Ort, um mit diesem Workflow zu experimentieren.

Deine nächste Änderung ist ein guter Zeitpunkt, zu starten. Wähle eine Ecke der App und mach sie heute schon änderungsfreundlich.