Frontend-Architektur für Designsysteme

Kapitel 10. Red Hat Prozess

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Bei Red Hat hat unser Frontend-Entwicklungsteam den unglaublichen Vorteil, dass wir der Backend-Entwicklung mehrere Sprints voraus sind. Wir setzen uns langfristige Ziele für die Funktionen, die wir bauen oder aktualisieren wollen, und sobald wir einen abgesegneten Prototyp haben, übergeben wir ihn zur Umsetzung an unser Entwicklungsteam.

In früheren Projekten haben wir vielleicht gesagt: "OK, hier ist das Markup, das du versuchen sollst auszugeben. Bitte kommt so nah wie möglich heran." Wir haben das Markup in einer Reihe von Mustache- oder Twig-Templates erstellt und dann unser Entwicklungsteam gebeten, PHP-, Ruby-, Angular-, React- oder Ember-Templates zu erstellen, die das gleiche Markup ausgeben. Das Problem bei diesem Ansatz ist, dass die Hälfte des Kampfes bei der Implementierung darin besteht, das vom Backend ausgespuckte Markup auch nur annähernd an unsere Prototypen anzupassen. Wir würden ständig mit Fehlern zu kämpfen haben, die nichts anderes sind als "das Markup, das von unserem CMS kommt, stimmt nicht mit unserem Prototyp überein".

Selbst wenn das Markup mit unserem Prototyp übereinstimmte, mussten wir immer befürchten, dass entweder der Prototyp oder der CMS-Code nicht mehr synchronisiert waren. Es wurden Änderungen an einem System vorgenommen, die im anderen System nicht berücksichtigt wurden, und irgendwann ...