Interview mit Sebastian Bergmann
Normalerweise bedanke ich mich ja an erster Stelle, dass sich mein Gegenüber für dieses Interview bereit erklärt hat. Bei Dir würde ich gerne erst mal den Dank für PHPUnit loswerden. Für uns sind Unit Tests ein sehr mächtiges Qualitätswerkzeug geworden. Ok, genug der Lobhudelei und wieder zurück zu den harten Fakten der PHP-Welt. Also, vielen Dank dass Du Dir die Zeit genommen hast, uns ein paar Fragen zu beantworten.Stell Dich doch einfach erstmal mit ein paar Worten vor.
Ich mag es normalerweise gar nicht, über mich selbst zu sprechen bzw. zu schreiben, daher nur ein paar Stichworte: Sebastian Bergmann. 30 Jahre alt. Diplom-Informatiker. Als Open-Source-Entwickler seit den Anfängen von PHP 4 im PHP-Ökosystems involviert. Entwickler von PHPUnit. Anbieter von Consulting, Coaching und Training, um Unternehmen bei Einführung und Verbesserung ihrer Qualitätssicherungsprozesse für PHP-Projekte zu helfen.
PHPUnit ist wohl eines der bekanntesten und beliebtesten Frameworks für das Testen von PHP-Anwendungen. Was ist es für ein Gefühl, ein Tool geschrieben zu haben, dass von Tausenden von PHP-Entwicklern genutzt wird?
Das ist natürlich ein gutes Gefühl. Bis auf die Momente, in denen man etwas in PHPUnit ändern möchte, es aber (zumindest noch) nicht kann, da dies mit zu großen Problemen für die Nutzer von PHPunit verbunden wäre.
Warum hast Du Dich für PHP und nicht für Java entschieden?
Diese Frage hat sich für mich so nie gestellt. Ein Bekannter aus der Amiga-Szene, in der ich den Spaß am Programmieren gefunden habe, fragte mich im Herbst 1998, ob ich für ihn in PHP oder Perl eine dynamische Webseite programmieren könne. Zu diesem Zeitpunkt kannte ich beide Programmiersprachen noch nicht, und ich schaute mir beide erst einmal an. Ich entschied mich dann für PHP, damals in Version 3, da die gegebene Aufgabe mit PHP wesentlich einfacher und eleganter zu lösen war als mit Perl.
Ich meine in Java hättest Du viele der Tools, die jetzt in PHP nachgezogen werden, wie zum Beispiel JUnit, schon zur Verfügung gehabt…
Dann hätte ich mich aber um die Freude, die es macht, ein Werkzeug wie PHPUnit zu entwickeln, gebracht.
…Auch die Sprachen ähneln sich. Ich muss dazu sagen, dass ich genau vor der gleichen Entscheidung stand und mich auch für PHP entschieden habe.
Richtig. Guter PHP-5-Code von wiederverwendbaren Bibliotheken und Komponenten sieht aus wie Java-Code. Die Tatsache, dass PHP sowohl die objektorientierte als auch die prozedurale Programmierung unterstützt ermöglicht es auch Einsteigern, mächtige PHP-Komponenten, die entweder in PHP oder in C implementiert sind, mit ein paar Zeilen Code zusammenkleben zu können. PHP ist eben die “Glue Language of the Web”.
Du hast Dich in den letzten Jahren auf Qualität im Entwicklungsprozess konzentriert. Macht es einem PHP nicht ziemlich schwer diese Ziele zu verfolgen?
PHP ist eine dynamisch (wie beispielsweise Python oder Lisp) und schwach (wie beispielsweise C oder JavaScript) typisierte Programmiersprache. Der kompilierende Teil des PHP-Interpreters kann also weit weniger statische Überprüfungen des Programms vornehmen als es beispielsweise ein C++- oder Java-Compiler kann. Dieser vermeintliche Nachteil einer Programmiersprache wie PHP lässt sich aber mit der Verwendung von Unit Tests mehr als ausgleichen. Diese ersetzen nicht nur die statischen Typüberprüfungen einer Compilers mit Typüberprüfungen zur Laufzeit, sondern stellen ferner sicher, dass der Code als Ganzes das tut, was er soll.
Wirkliche Probleme bekommt man erst dann, wenn man PHP-Code einer statischen Code-Analyse unterziehen möchte: variable Variablennamen sowie variable Funktions- und Methodenaufrufe machen einem hier schnell das Leben schwer.
Das Thema Qualität spielt erst seit 1-2 Jahren eine Rolle in der PHP-Community. Als ich vor knapp 8 Jahren mit der Entwicklung von PHPUnit begonnen habe gab es keine Werkzeuge für die Qualitätssicherung von PHP-Projekten. Kein PHPUnit, kein PHP_CodeSniffer, kein PHP_Depend, kein phpUnderControl. Jetzt werden all diese Werkzeuge (und die mit ihnen verbundenen Praktiken und Prozesse) von immer mehr PHP-Entwicklern entdeckt.
Dass du ein viel beschäftigter Mann bist, kann man an deinen vielen Auftritten auf diversen Konferenzen sehen oder zumindest ahnen. Wenn du genügend Zeit hättest, gäbe es da ein Werkzeug oder Tool, dass du zusätzlich zu PHPUnit noch gerne schreiben oder portieren würdest?
Ich würde gerne mehr Zeit in mein BugMiner-Projekt (http://www.phpunit.de/wiki/BugMiner) investieren. Dieses kann Fragen wie “Welches sind die Methoden, Klassen, Dateien mit den meisten Bugs?” beantworten.
Du bist viel in beratender Tätigkeit unterwegs und so bleibt es einem natürlich nicht erspart, viele Projekte gesehen zu haben. Hand aufs Herz, ist es oft der Fall, dass man denkt: “Meine Güte, unglaublich, dass man auf diese Art eine so umfangreiche Software schreiben konnte”.
Natürlich. Gerade wenn man auf eine Code-Basis trifft, deren Ursprünge noch in der PHP-3-Zeit liegen.
Wie immer kommen wir jetzt zu einer unserer Standardfragen, die wir aber nicht weglassen können. Wann hast du das letzte mal gedacht, dass PHP Dich hassen muss, denn ansonsten hätte es sich nicht so verhalten, wie es das gerade getan hat?
Hin und wieder ärgere ich mich ein wenig über Dinge wie ReflectionProperty::setAccessible(), das nur für ReflectionProperty::getValue() funktionieren soll, nicht aber für ReflectionProperty::setValue().
Manchmal ist es recht mühsam, einem Bug in PHP auf den Grund zu gehen. Ärgerlich war beispielsweise die Suche nach Bug #45805. Umso dankbarer und glücklicher ist man jedoch, wenn ein solcher Bug binnen Stunden behoben wird, wie in diesem Fall durch Dmitry.
Jetzt kommen wir auch schon zu unserer letzten Frage. Mit wem würdest du gerne mal in einem Projekt Pair Programming machen?
Nicht wirklich Pair Programming, aber ich wünsche mir ein Treffen der Entwickler von JUnit, TestNG, py.test, PHPUnit, Selenium, etc. Ich bin mir ziemlich sicher, dass wir viel von einander lernen können und in manchen Punkten zusammenarbeiten können, wie beispielsweise das Hamcrest-Projekt zeigt.
Also nochmal vielen Dank, dass Du Dir die Mühe gemacht hast und vielleicht sieht man sich ja auch der nächsten PHP-Konferenz.