TYPO3-Updates: Warum kleine Teams am längsten zögern
Ein Werkzeug, ein Job, ein Mechaniker
Kelly Johnson leitete in den 1960er-Jahren das Skunk-Works-Programm bei Lockheed, dem Team, das den Spionagejet U-2 und später die SR-71 Blackbird entwickelte. Eines seiner bekanntesten Arbeitsprinzipien lautete: Ein Flugzeug soll so gebaut sein, dass ein durchschnittlicher Mechaniker mit Standardwerkzeug es unter Feldbedingungen reparieren kann. Nicht der Chefingenieur, nicht ein Spezialist mit Sonderwerkzeug, sondern jemand mit Grundausbildung, unter Zeitdruck, ohne Rückfragemöglichkeit.
Er nannte es KISS: Keep It Stupid Simple.
Der Satz klingt nach Sparsamkeit. Er meint das Gegenteil: Qualität. Einfache Konstruktionen sind wartbar, testbar, transferierbar. Komplexe Konstruktionen hängen am Wissensvorsprung einzelner Personen, und das rächt sich spätestens dann, wenn diese Person das Unternehmen verlässt oder das Projekt an eine andere Agentur übergeben wird.
In der Software-Entwicklung gilt dasselbe Prinzip, denn Code soll so geschrieben sein, dass ein anderer Entwickler ihn ohne intensive Einführung versteht. Nicht kommentiert bis zur Unleserlichkeit, sondern strukturiert bis zur Selbsterklärung.
Was das in TYPO3 konkret bedeutet
TYPO3 ist ein System, das Komplexität ermöglicht — die Grundlage seiner Flexibilität. Und genau diese Flexibilität erzeugt eine Versuchung: mehr Extensions, mehr TypoScript-Verschachtelungen, mehr Sonderlösungen für jede erdachte Anforderung. Das Ergebnis ist eine Installation, die drei Jahre nach dem Launch niemand mehr ohne erheblichen Aufwand anpassen kann, da das implizite Wissen über die Konfiguration in keinem Dokument steht, sondern in den Köpfen derjenigen, die sie gebaut haben.
KISS in TYPO3 heißt: das Gegenteil wählen.
Extensions: so wenige wie nötig
Jede Drittanbieter-Extension ist eine Abhängigkeit. Sie hat einen Maintainer, der sie aktualisiert oder auch nicht. Sie hat einen Code-Stand, der mit dem nächsten TYPO3-Major-Release kompatibel ist oder Anpassungsaufwand erzeugt. Sie bringt Konfiguration mit, die mit der eigenen Installation in Konflikt geraten kann, sodass beim nächsten Update plötzlich unerwartete Wechselwirkungen auftreten.
Die entscheidende Frage lautet deshalb nicht: Gibt es eine Extension, die das kann? Sondern: Brauchen wir diese Extension wirklich, oder lässt sich das einfacher selbst lösen?
Ein konkretes Beispiel: Für eigene Inhaltselemente wurde in der TYPO3-Welt lange auf MASK gesetzt, einen Extension-Builder, der benutzerdefinierte Felder und Templates generiert. Das funktioniert. Es entsteht allerdings schnell eine Situation, in der fünf MASK-Konfigurationen fünf ähnliche Aufgaben erledigen, jede mit eigenem Overhead, eigenen Konventionen und eigenem Wartungsaufwand. ContentBlocks, der neuere standardisierte Weg zur Definition eigener Content-Elemente in TYPO3, schafft hier Klarheit: eine Schnittstelle, eine Konvention, weniger Ausreißer. Wer künftig in die Installation schaut, muss nicht erst fünf MASK-Konfigurationen auseinanderhalten.
TypoScript und Fluid: klar statt clever
TypoScript kann alles. Das ist sein Problem. Wer lange genug sucht, findet Wege, Logik in TypoScript zu bauen, die eigentlich ins Template gehört, ins PHP oder gar nicht existieren sollte. Fluid Templates lassen sich tief verschachteln, sodass eine Änderung an einem Randelement vier Dateien betrifft und die eigentliche Ursache im dritten Partial vergraben liegt.
KISS heißt hier: klare Zuständigkeiten. TypoScript konfiguriert, Fluid rendert, PHP verarbeitet. Jede Ebene macht das, was sie am besten kann. Wer ein Template öffnet und in drei Minuten versteht, was es tut, hat gute Arbeit geleistet. Wer nach zehn Minuten noch sucht, hat ein Komplexitätsproblem, das früher oder später teuer wird.
Composer, Tests und die Frage des Risikos
Composer ist heute Standard in der professionellen TYPO3-Entwicklung, da er Abhängigkeiten verwaltet, den Installationszustand reproduzierbar macht und Updates erheblich erleichtert. Die Alternative, nämlich manuelle Datei-Verwaltung, Extensions per Upload und Versionen per Hand gepflegt, ist fehleranfällig und zieht den Wartungsaufwand dauerhaft in die Höhe. Kein Trend. Handwerk.
Tests sind ein zweischneidiges Instrument. Ein vollständiger Test-Overhead für eine Website, deren Inhalte sich selten ändern und deren Kernfunktion statisch ist, rechtfertigt den Aufwand nicht. Tests dort, wo Formulare kritisch sind, wo Berechnungen korrekt sein müssen, wo ein Fehler unmittelbare Konsequenzen für den Betrieb hat: das ist sinnvoll und gehört zum Lieferumfang.
Wir benennen das Risiko. Was getestet wird und was nicht, entscheidet der Kunde. Unsere Aufgabe ist es, den Umfang transparent zu machen, nicht eine Test-Coverage zu verkaufen, die über das hinausgeht, was die Installation tatsächlich braucht. Das ist auch KISS: nicht Test-Theater, sondern gezielte Absicherung.
Einfachheit ist eine Kompetenz, keine Abkürzung
KISS setzt voraus, dass der Entwickler gut genug ist, um einfach zu bauen. Das ist nicht selbstverständlich. Einfache Lösungen sind oft schwerer zu finden als komplexe, da die komplexe Lösung die ist, die zuerst funktioniert. Die einfache Lösung verlangt, dass man nochmal hinschaut. Brauchen wir diese Abstraktion wirklich? Geht das kürzer? Ist die Extension notwendig, oder bauen wir hier Schicht auf Schicht, weil es im Moment bequemer ist?
Es gibt Situationen, in denen eine Drittanbieter-Extension kurzfristig schneller ist als eine Eigenentwicklung. Das ist legitim. Die Kosten entstehen später: im Update-Prozess, wenn die Extension nicht mehr gepflegt wird; in der Übergabe, wenn ein neuer Entwickler die Installation übernimmt; im Support, wenn ein Fehler tief in fremdem Code liegt und niemand mehr versteht, warum das so gebaut wurde.
Unsere Haltung: Wenn wir fertig sind, ist das Ergebnis nicht einfacher, sondern klar. KISS ist kein Budget-Argument und kein Vorwand, Features wegzulassen. Es ist ein Qualitätsanspruch, der sich über die Laufzeit einer Installation auszahlt, weil wartbarer Code billiger zu betreiben ist als schlauer Code.
Der Unterschied zu Minimalismus ist folgender: Minimalismus lässt weg, was stört. Einfachheit lässt weg, was nicht notwendig ist, und behält, was gebraucht wird, um eine Installation wartbar, updatefähig und für eine nachfolgende Agentur oder einen neuen Entwickler zugänglich zu halten.
Das ist es, was Johnson meinte. Nicht weniger bauen. Besser bauen.
