Robert Lemke von TYPO3 FLOW im Interview

Ein Framework muss eine klare Aussage darüber treffen, was sein Schwerpunkt ist.
Kommentare

Große Projekte basieren zu einem großen Teil auf einem der zahlreichen Frameworks, die das PHP-Universum zu bieten hat. Dabei ist nicht die Frage, ob man ein Framework benutzt, sondern viel mehr: welches und warum. Doch wie sieht das eigentlich jemand, der selbst an einem viel beachteten Framework gearbeitet hat?

Wir sprachen mit Robert Lemke über die Intentionen, die das Team bei der Entwicklung von TYPO3 FLOW getrieben hat, über den Sinn und Unsinn von Frameworks und darüber, ob man als Entwickler eines Frameworks tiefer in Problemlösungen steckt.

PHP Magazin: Robert, du zeigst dich verantwortlich für TYPO3 FLOW, ein Framework, das mittlerweile nicht mehr nur im TYPO3-Projekt zum Einsatz kommt. Was ist das für ein Gefühl, sein „Baby“ so fliegen zu sehen?

Robert Lemke: Letzte Woche fand ja die Inspiring Conference statt, und es gab da schon einen Moment, in dem ich so von hinten über die 250 Teilnehmer geschaut habe und dachte: „Verrückt, dass sich Leute aus aller Herren Länder treffen, um über eine Software zu reden, die du mal gestartet hast“. Aber das eigentliche Glücksgefühl habe ich bei dem Gedanken, dass das Projekt inzwischen nicht mehr nur in meiner Hand liegt. Das hat eine eigene Dynamik entwickelt, mit einem Core-Team von über 25 Leuten und Menschen, die sowohl mit Flow also auch mit TYPO3 Neos tolle Dinge anstellen, die ich mir früher gar nicht vorstellen konnte.

Was waren eure Maßstäbe, als ihr euch an die Arbeit gemacht habt?

Robert: Einfachheit und Professionalität. Flow sollte das Framework werden, das trotz seiner Mächtigkeit durch Konventionen und einer Menge Hilfestellungen einfach zu nutzen ist. Wir haben im Laufe der Entwicklung schon so viel Code wieder weggeschmissen weil er einfach nicht mehr notwendig war, da darf man wirklich nicht emotional werden und darüber nachdenken, wie lange man an dem Code entwickelt hat. Ich habe knapp 7 Jahre als Editor und Bildtechniker beim Fernsehen gearbeitet und fand es immer beeindruckend, wie viel Aufwand in scheinbar unwichtige Details gesteckt wird. Dieser Qualitätsanspruch ist sicherlich auch in Flow und Neos eingeflossen.

Hattet ihr eine feste Architektur im Kopf, die ihr mit dem Framework umsetzen wolltet?

Robert: Nein, so vorausdenkend war ich dann doch nicht. Aber es gab ein paar schicksalshafte Begegnungen mit anderen Frameworks und Programmiersprachen, die zum Beispiel dazu führten, schon von Anfang an Dependency Injection und Aspekt-Orientiertes Programmieren in Flow zu unterstützen. Ich glaube meine eigentliche Stärke in diesem Projekt ist die Erfahrung, denn ich programmiere mittlerweile seit fast 26 Jahren. Du kannst Refactoring, Testing und Design Patterns recht schnell lernen, aber wenn es dir in Blut und Seele übergegangen ist, siehst du sofort Muster im Code und der Architektur, die nicht stimmig sind und weißt auch, wie du diese „Bad Smells“ ändern kannst. Flow ist nur deshalb so gut geworden, weil wir über die Jahre so viele Iterationen hatten, in denen wir vieles in Frage gestellt und erneuert haben.

Als jemand, der durch eine harte Schule gegangen ist, indem du selbst ein Framework entwickelt hast und dabei lernen musstest, dass man gerne einmal falsche Entscheidungen dabei trifft – was erwartest du von einem Framework? Was muss es leisten, und vor allem: welche Freiheiten muss es dir lassen?

Robert: Ein Framework muss zunächst einmal eine klare Aussage darüber treffen was sein Schwerpunkt ist: Geschwindigkeit? Einfachheit? Robustheit? Oder geht es zum Beispiel darum, dass man möglichst viele Teile des Frameworks auch als eigenständige Komponenten verwenden kann? Wenn ich mir ein eigenes spezialisiertes Framework bauen möchte, brauche ich heute nicht mehr bei Null anzufangen, sondern kann mir ein Framework suchen, das aus vielen lose-gekoppelten Komponenten besteht. Dann habe ich die volle Flexibilität. Wenn ich mir eine Applikation bauen möchte und nicht so viel darüber nachdenken möchte wie man ein Framework entwickelt, dann nehme ich vielleicht eine Lösung, die schon ein Gesamtkonzept und eine Basis-Architektur bietet.

Es gibt inzwischen wirklich gute Frameworks, nur kann man jedes davon auch falsch nutzen. Ein ORM wie zum Beispiel Doctrine nimmt dir eine ganze Menge Arbeit ab, wenn es darum geht, Objekte in einer Datenbank zu speichern. In Verbindung mit Flow ist das so einfach zu benutzen, dass man völlig vergisst, dass da ein ORM hinter steckt. Das ist aber auch die Gefahr, denn wenn man zum Beispiel ohne es zu merken sämtliche Daten in den Speicher lädt, um mit einer for-Schleife eines davon auszuwählen, bekommt man arge Performance-Probleme. Der Vorteil an Frameworks ist, dass man nicht alles, was das Framework leistet, von Anfang an selbst können muss. Es hilft aber sehr, Schritt für Schritt zu lernen was da eigentlich passiert, vielleicht sogar mal selbst ein kleines Framework zu entwickeln.

Ist es deiner Meinung nach immer sinnvoll, auf ein Framework zu setzen?

Robert: Es ist ja auch nicht immer sinnvoll guten Kaffee zu trinken. Aber meistens schon 🙂 (Anm. d. Red.: Falschaussage – es ist immer sinnvoll, guten Kaffee zu trinken!)

Ein Framework nimmt einem unglaublich viele Details ab, an die man im vornherein noch gar nicht denken mag. Andererseits bringt es auch eine Komplexität, die in manchen Projekten gar nicht notwendig wäre. Es lohnt sich immer zunächst zu überlegen, was eigentlich das Ziel ist – für viele ist das Framework schon gesetzt, bevor überhaupt die Aufgabe klar ist. Ich schätze mal, dass viele, die ein Framework nutzen, entweder auch ohne eines klar kämen oder vielleicht auch aus emotionalen Gründen das für ihre Zwecke eigentlich falsche Framework gewählt haben.

Ein wenig ketzerisch vielleicht, aber glaubst du, dass ihr als Framework-Entwickler tiefer in Problemlösungen steckt?

Robert: Ich denke dass Framework Entwickler die nützliche Fähigkeit haben, weit voraus zu denken und schnell zu erfassen, was die Essenz eines Problems ist. Wenn man den ganzen Tag damit verbringt, möglichst generelle Lösungen zu schaffen, geht man so auch an Kundenprojekte ran und arbeitet vielleicht eher mit Techniken wie mit den Five Whys. Es besteht aber natürlich auch die Gefahr, zu schnell zu generalisieren. Für mich funktioniert da das Grundprinzip „Three Strikes and you Refactor“ sehr gut.

Das klingt danach, als würden wir auf dem Framework Day noch viel tiefere Einblicke bekommen. Danke, dass du dir die Zeit genommen hast!

Robert Lemke auf der International PHP Conference 2014 Spring Edition

International PHP Conference 2014Robert Lemke ist Projektgründer und Architekt des TYPO3-Flow-Frameworks und von TYPO3 Neos, einem neuen Content-Management-System des TYPO3-Projekts. Er hat eine besondere Leidenschaft für sauberen Code und unterstützt als als Senior Software Architect und Consultant bei der TechDivision GmbH Firmen dabei, erfolgreiche Flow-Projekte umzusetzen. Außerdem ist er Sprecher auf dem Framework Day der International PHP Conference 2014.

Einen Überblick über die Sessions des Special Days findet ihr auf der Übersichtsseite zum Framework Day.

Aufmacherbild: Question and information speech bubble icons, three-dimensional rendering von Shutterstock / Urheberrecht: Oakozhan

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -