© svetabelaya/Shutterstock.com
Sulu CMS mit dem Blick auf eine gute Developer Experience

Auf den Schultern von Riesen bauen


Als wir 2013 mit der Arbeit an Sulu anfingen, war der CMS-Markt überfüllt. Wir hätten auf ein eigenes CMS verzichten können, zugunsten eines der anderen auf dem Markt. Aber uns fehlte ein System mit hervorragender Developer Experience (DX).

Was ist Developer Experience? Und warum ist es wichtig? Es wird oft versucht, zu viele Probleme zu lösen, was zu aufgeblähten Systemen führt. Und viele versuchen, Probleme auf ihre eigene Weise zu lösen. Das Ergebnis: steile Lernkurven und hart erarbeitete Kenntnisse, die man nicht wiederverwenden kann. All dies sind Zutaten für eine miese Developer Experience (Entwicklererfahrung, DX) und viel Frustration. Devs (uns selbst!) an erste Stelle zu setzen, war schon immer eine unserer Hauptmotivationen. Wir wollten sich wiederholende, übermäßig komplizierte oder überflüssige Aufgaben vermeiden, um stattdessen möglichst viel wichtige und interessante Arbeit leisten zu können. Zum Glück gewinnt DX allmählich an Aufmerksamkeit, und es gibt Konferenzen, die sich diesem Thema widmen.

Laut den Forschern Fabian Fagerholm und Jürgen Münch [1] besteht die Developer Experience aus Erfahrungen mit allen Arten von Artefakten und Aktivitäten, denen ein Entwickler im Rahmen seiner Beteiligung an der Softwareentwicklung begegnen kann. Ihnen zufolge kann DX in folgende Bereiche unterteilt werden:

  • Entwicklungsinfrastruktur

  • Gefühle der Entwickler bezüglich ihrer Arbeit (z. B. Respekt, Bindung, Zugehörigkeit)

  • den Wert des Entwicklungsbeitrags

CMS wie Sulu gehören zum Toolset eines Entwicklers, was bedeutet, dass sie in erster Linie für die erste Kategorie, die Entwicklungsinfrastruktur, relevant sind. Wir glauben, dass unser Ansatz auch Entwicklern hilft, sich ernst genommen und in ihrer Arbeit wertgeschätzt zu fühlen. So ist das Deployment viel schwieriger, wenn Konfiguration in der Datenbank gespeichert wird. Die Tatsache, dass wir strikte Trennung von Inhalt und Konfiguration umgesetzt haben, zeigt, dass uns ihre Bedürfnisse wichtig sind. Und, wie wir weiter unten diskutieren werden, hilft die Bereitstellung einer übersichtlichen Editoroberfläche, die für Entwickler einfach aufzubauen ist, allen – auch weniger technisch versierten Kollegen – dabei, die Früchte der Entwicklungsarbeit zu schätzen. Unserer Ansicht nach zeichnet sich eine gute Developer Experience durch weniger verschwendete Entwicklungszeit aus, was die vorhandenen Ressourcen maximiert. Schließlich ist das Onboarding von Entwicklern auf ein System, das auf einem gängigen Framework (in unserem Fall Symfony) basiert, weniger zeitintensiv als die Einarbeitung neuer Mitarbeiter*innen in firmeninterne oder unbekannte Technologien. Ich möchte hier Tipps für eine bessere DX teilen, die aus über sechs Jahren Arbeit an Sulu hervorgegangen sind.

Tipp 1: Baue auf Tools, die deine Leute kennen

Sulu baut auf dem bei Entwicklern beliebten Symfony-Framework auf und bietet Tools und Infrastrukturen, die den Entwicklungsprozess vereinfachen. Sobald du die Grundlagen wie Routing, Controller und Dependency Injection kennst, kannst du sie in jedem Projekt anwenden. Wir sind der Meinung, dass Symfony die richtige Balance schafft, den Entwicklern möglichst wenig Zwänge aufzuerlegen und dabei trotzdem häufig verwendete Funktionen bereitzustellen, damit sie nicht alles selbst schreiben müssen. Mit Symfony kannst du das verwenden, was du benötigst, die unerwünschten Elemente ignorieren und deine Anwendung schlank halten, ohne das Rad ständig neu erfinden zu müssen. Symfony hilft dir auch, im Lauf der Zeit immer besser zu arbeiten. Wenn du eine Funktion einmal entwickelt hast, kannst du sie an anderer Stelle wiederverwenden, sofern du die Symfony-Standards eingehalten hast. Du kannst sie innerhalb desselben Projekts genauso wie in anderen Projekten einsetzen oder der Open-Source-Community als Symfony-Bundle zur Verfügung stellen. Das kommt uns als Entwicklern von Sulu und den Entwicklern, die mit Sulu arbeiten, zugute. Wir müssen nichts entwickeln, was bereits existiert. Stattdessen profitieren wir von der Arbeit Tausender anderer Entwickler und konzentrieren uns auf das, was wir am besten können: die Bereitstellung spezifischer CMS-Funktionen, die Symfony nicht kann oder die Entwickler sonst selbst erstellen müssten. Das bedeutet auch, dass wir nicht annähernd so viel Dokumentation schreiben müssen, da wir nur die Teile dokumentieren müssen, die Symfony erweitern.

Für Entwickler*innen, die bereits mit Symfony vertraut sind, ist die Lernkurve des Sulu CMS ziemlich flach. Du kannst vorhandene Tools, Arbeitspraktiken und Erfahrungen in jedes CMS-Projekt einbringen. Erstellst du beispielsweise eine Webanwendung, die eine komplexe Datenstruktur erfordert, kannst du deine Geschäftslogik mit Symfony erstellen und mit Sulu CMS-spezifische Funktionen dort bereitstellen, wo du sie benötigst.

Wir sprechen oft davon, dass Entwickler CMS verbiegen, um Dinge zu tun, für die sie nicht entwickelt wurden. Aber jedes Mal, wenn man einen Symfony-Entwickler dazu zwingt, obskure Coding-Standards zu erlernen, im Internet nach einem nicht intuitiven Klassennamen zu suchen oder unbekannten Code zu debuggen, dann verbiegt das System den Entwickler – nicht umgekehrt. Symfony-Entwickler möchten mit Symfony entwickeln. Wir geben ihnen ein Werkzeug, das sowohl brandneu als auch absolut vertraut ist.

Tipp 2: Open Source für dein Projekt

Wächst deine Open-Source-Community, profitieren alle: du, die Community der Benutzer und deine Software. Das Wachstum und die Förderung einer Entwicklungsgemeinschaft für eine Open-Source-Lösung erfordern viel Arbeit und Engagement. Akzeptanz und Einsatz sind für Open-Source-Projekte von entscheidender Bedeutung, und es kann sich auszahlen:

  • Je größer deine Open-Source-Community wird, desto mehr Mitglieder der Community melden Fehler oder schlagen zusätzliche Funktionen vor. Einige tragen Patches und Ergänzungen bei. Ein Closed-Source-Projekt kann dagegen von diesen zusätzlichen Ressourcen nicht profitieren. Bis Ende 2019 hatten wir insgesamt 94 Mitwirkende an Sulu, von denen 24 jeweils zehn oder mehr Commits getätigt haben.

  • Jedes Mal, wenn du einen Pull Request annimmst oder dich für den Beitrag bedankst, fühlt sich jemand geschätzt und motiviert. Es ist auch für uns sehr erfüllend, wenn wir sehen, dass unsere Arbeit einer breiteren Gemeinschaft zugutekommt. Das trägt erheblich zur allgemeinen Developer Experience eines Projekts bei.

  • Eine umfangreichere externe Nutzerbasis sieht, was du nicht siehst. Unsere Community hat uns geholfen, Fehler zu finden, und uns viel DX-Feedback gegeben. Zum Beispiel sah sie Inkonsistenzen in der Art und Weise, wie wir Konstanten und Klassen benannt hatten, die wir intern übersehen hatten.

  • Verwendet niemand dein Projekt, kümmert sich auch niemand darum. Personen, die dein System nicht nutzen, können keine Rückmeldung geben und haben keinen Anreiz, Zeit in Verbesserungen zu investieren.

  • Evangelisieren: Wir sind keineswegs das einzige CMS auf dem Markt, aber das Bewusstsein für Sulu wä...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang