spaghetti code vermeiden

Ich habe mich lange gegen “zentrales Management” gewehrt. Es klang nach Kontrolle, nach Überwachung, nach irgendeinem Architektur-Komitee, das dir erklärt, dass du deinen Dialog jetzt bitte in dreifacher Ausführung beantragen musst. Also habe ich das Gegenteil gebaut: verteilte Verantwortung. Jede Komponente, jeder Screen, jedes Feature durfte selbst entscheiden, wann es Dialoge zeigt, was wichtig ist und wie der Nutzer “geführt” werden soll.Spoiler: Das fühlt sich am Anfang frei an – und später wie eine WG ohne Putzplan.Denn Dialoge sind keine UI-Spielerei. Sie sind Produktlogik in Verkleidung: Login abgelaufen, Offline-Modus, Berechtigungen, Updates, Fehlermeldungen, Feature-Hinweise. Jeder einzelne Dialog hat Bedingungen, Timing, Priorität und Konflikte (“nicht während Checkout”, “nicht wenn schon ein anderer Dialog offen ist”, “nicht zum dritten Mal diese Woche”). Wenn diese Regeln verteilt im Code leben, passiert das Unvermeidliche: Logik wird kopiert, widerspricht sich, driftet auseinander. Und plötzlich musst du wegen einer kleinen Regeländerung an sieben Stellen im Code herumoperieren, während du dir einredest, das sei normal.Die Lösung ist nicht “mehr Kontrolle”, sondern klare Verantwortung: Ein zentraler Dialog-Orchestrator, der Trigger von außen annimmt, Regeln über Policies prüft und Dialoge über eine Queue priorisiert. Nicht als God Object, sondern als Verkehrsleitung. Dann ist die UI wieder UI, Features sind wieder Features – und dein Produkt verhält sich nicht mehr wie ein Zufallsgenerator mit Push-Nachrichten.