PHP ist nicht kaputt!
Kommentare

„How PHP is Broken and How It Can Be Fixed“ titelte Court Ewing von Engine Yard vor einigen Wochen in seinem Blog, wo er Mängel im PHP Release-Prozess anprangerte, die beispielsweise zur Veröffentlichung

How PHP is Broken and How It Can Be Fixed“ titelte Court Ewing von Engine Yard vor einigen Wochen in seinem Blog, wo er Mängel im PHP Release-Prozess anprangerte, die beispielsweise zur Veröffentlichung von PHP 5.3.7 führen konnten. Bekanntlich war dem PHP-Core-Team ein sicherheitskritischer Bug in der Funktion crypt() entgangen, der kurz darauf aber gefixt wurde.

In einem neuen Blogpost geht Ewing nun konstruktiver ans Werk und unterbreitet Vorschläge, wie der Release-Prozess von PHP verbessert werden könnte, um ähnliche Super-GAUs zu vermeiden.

Immerhin hat das PHP-Core-Entwicklerteam bereits einen RFC angenommen, in dem eine Roadmap für die kommenden PHP-Releases festgesetzt wird. Auch ein Abstimmungssystem wurde etabliert, um kollektiv über neue Features zu entscheiden. Auf einer offiziellen Seite werden die Codeabdeckungstests gesammelt und analysiert.

Doch was hilft´s, wenn es zum Usus gehört, dass fehlschlagende Tests hingenommen und fehlerhafte Releases nicht verhindert werden? Was hilft es, wenn Verantwortlichkeiten unklar sind und die wenigen Kommunikationswege nicht hinreichend genutzt werden?

Testabdeckung – und was sie bewirken sollte

Ewing stellt fest, dass in den letzten Jahren in Sachen Testabdeckung durchaus Fortschritte erzielt worden sind. PHP 5.3 verfügt über 70% Testabdeckung. Das Problem mit den automatisierten Test sei aber nicht, dass nicht genügend davon existierten, sondern dass keine Notwendigkeit bestehe, dass die Tests bestanden werden. Auch neuer Code muss nicht unbedingt über eine ausreichende Testabdeckung verfügen. Als Beweis führt Ewing die 128 fehlschlagenden Unittests in PHP 5.3 und die 129 in PHP 5.4 an – keine Anzeichen also, dass sich die Situation verbessert hat.

Als Konsequenz der Praxis, fehlschlagende Test hinzunehmen, gab es den Bug in PHP 5.3.7. Die automatischen Tests haben wohl den Fehler erkannt, das Release wurde aber trotzdem ausgeliefert. Wahrscheinlich ein menschlicher Fehler, so Ewing, der natürlich vorkommen kann, den man aber durch bessere Prozesse hätte verhindern können.

Deshalb macht Ewing Vorschläge:

  • Das PHP-Core-Team sollte Ziele für die Testabdeckung definieren. Ideal wären sicherlich 100%, aber alles über 80 % findet Ewing zum jetzigen Zeitpunkt gut.
  • Darüberhinaus sollten alle neuen Features als Bedingung korrespondierende Tests mitliefern, die die Zielvorgaben erfüllen. Und natürlich sollten alle neuen Tests bestanden werden.
  • Schwieriger wird es, die aktuell angezeigten Fehler aus den roten Tests zu beseitigen. Hier liege die Verantwortung nicht nur beim Kern-Entwicklerteam, auch viele Committer könnten helfen. Eventuell stammen die Fehler auch von Komponenten, die nicht mehr aktiv gewartet werden.

Resolving all of the failing tests will no doubt require both an increased effort by the existing core developers as well as an increase in the number of contributors.

Die Wege der Kommunikation
Das Schlimme an PHP 5.3.7 war für Ewing nicht der Bug an sich, sondern dass dieser schlecht kommuniziert wurde. Als einzige Kommunikationswege existieren bisher die php.announce Mailing-Liste und der News-Feed auf PHP.net. Kein Developer-Blog, kein offizieller Twitter Account, keine Facebook-Seite.

In der Tat wurde der Bug in PHP 5.3.7 innerhalb von zwei Tagen gefixt und ein Update ausgeliefert – innerhalb von fünf Tagen, eine großartige Zeit. Dennoch gab es in diesen Tagen kein offizielles Wort vonseiten des Core-Teams über die Existenz des Bugs. Folge: Gerüchte machten sich breit, das Vertrauen in die Kernentwickler wurde erschüttert.

Wünschenswert wäre für Ewing deshalb ein Entwicklerblog, in dem die Kernentwickler die neuen Features diskutieren und Ankündigungen machen könnten, wenn einmal etwas schief läuft.

PHP is not broken
Vorschläge, die in die richtige Richtung gehen, und die der Professionalisierung des PHP-Bereichs zugute kommen würden. Abschließend wird Ewing noch seine persönliche Liebeserklärung an PHP los: Denn seine Kritik komme nicht aus einem zerstörerischen Geist heraus, sondern entspringe dem Bedürfnis, das geschätzte PHP weiter voran zu bringen:

PHP is a stable, secure, and beautifully-practical language that is both easy for novices to wrap their heads around and experts to build the most-used web applications the world has ever seen. PHP is not broken, but there are areas that can definitely be improved. Fixing unit tests and polishing methods of communication should seem minor in comparison to the monumental accomplishments of the past 15 years.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -