Das Prinzip ist einfach: in der (abstrakten) Basisklasse wird eine leere Methode definiert, die durch eine konkrete Klasse überschrieben werden kann.

Der Vorteil ist recht offensichtlich. Die Methode kann ohne vorherige Prüfung verwendet werden und das spart an vielen Stellen unnötigen Code. Aus meinem ästhetischem Empfinden der richtige Weg.

Aber auch den anderen Weg habe ich auch schon desöfteren gesehen und mein Bauchgefühl hat ja auch nicht immer recht. Vielleicht ist der schöne Weg ja auch der langsamere?

Gefühl ist gut, Zahlen sind besser! Also habe ich schnell drei Testklassen geschrieben und probiere die verschiedenen Möglichkeiten durch.

Variante 1: Wir verlassen uns darauf, dass die Methode aufgerufen werden kann.

<?php
class Test1 {
    public function machWas() {
        $this->machWasAnderes();
    }

    public function machWasAnderes() {
    }
}

Variante 2: Wir prüfen, ob die Methode existiert und finden nichts.

<?php
class Test2 {
    public function machWas() {
        if (method_exists($this, 'machWasAnderes')) {
            $this->machWasAnderes();
        }
    }
}

Variante 3: Wir prüfen, ob die Methode existiert und rufen sie auf.

<?php
class Test3 {
    public function machWas() {
        if (method_exists($this, 'machWasAnderes')) {
            $this->machWasAnderes();
        }
    }

    public function machWasAnderes() {
    }
}

Zum Vergleich habe ich das folgende Script verwendet.

<?php
foreach (array('Test1', 'Test2', 'Test3') as $class) {
    $object = new $class();
    $start = microtime(true);

    for($i=0; $i<100000; $i++) {
        $object->machWas();
    }
    echo $class . ' = ' . round(microtime(true) - $start, 5) . '<br/>';
}

Ausgabe:

Test1 = 0.44767
Test2 = 0.48588
Test3 = 0.70881

In mehreren Durchläufen waren “Test1″ und “Test2″ immer fast gleich auf, nur “Test3″ brauchte etwas länger, weil in der Klasse die Prüfung und die Ausführung der Methode stattfindet.

Fazit: Der Einsatz von Schablonenmethoden lohnt sich doppelt, da der Code übersichtlich bleibt und auch die Geschwindigkeit etwas besser ist.

Wenn man Sebastian Bergmann hört, dann ist ja schon klar, dass es sich um ein QA- oder QM-Thema handelt und genau das ist es auch. im Prinzip geht es dabei nur um einen Commit-Hook. Ja ich weiß, da gibt es viele, aber was haltet ihr von der Idee, dass er einen darauf hinweist, wenn man vergessen hat eine Datei zu comitten oder sogar sie unzupassen? Hääh? Wie soll denn das gehen? Im Prinzip muss man nur folgende Aussage in den Raum stellen: “Wenn sie in der Vergangenheit Datei A comitted haben, dann haben sie auch immer Datei B angefasst.”

Finde den Ansatz genial. Er ist simpel und trotzdem scheint es effizient zu sein. So viel ich weiß, hat Sebastian dies sogar mal in PHP implementiert. Leider fehlen mir dazu die Links. Hatte mir nur die Idee gemerkt weil ich sie toll fand.

Ich würde ja gerne mehr darüber erzählen, aber die Idee ist ja schon in dem einen Satz wunderbar erklärt, deswegen wird es heute mal ein wenig kürzer und wir denken uns alle, wie toll es wäre, wenn wir das mal austesten dürften.

Jetzt kombinieren wir diese beiden Punkte einfach einmal. Wir bauen Zeugs, welches wir eh wegwerfen und ärgern uns über die Qualität der Dinge, die wir bauen. Irgendwie ein Widerspruch. Warum hohe Qualität bei Software die wir eh nicht wirklich benötigen.

Inspiriert hat mich Kris Köhntopp, als er ein wenig über den Alltag bei booking.com erzählt hat. Wie könnte man also vorgehen? Wir müssen unsere Software in zwei Teile gliedern. Der erste Teil beinhaltet alles, was sauber ist, zum Beispiel Core-Komponenten und auch erfolgreiche Features. Diese Gruppe muss sauber vom Aufbau und Testabdeckung sein. Mehr ist hier wirklich auch mehr.

Neue Features kommen erst mal in die Quarantänezone. Das geht bei kleineren und autarken Dingen wunderbar. Nehmen wir zum Beispiel die Top 5 Artikel auf phphatesme, wenn ich mir die Statistiken ansehe, wird mir klar, dass es ein unnötiges Feature ist. Also rausgeworfenes Geld, dass ich es damals sauber implementiert habe. Eigentlich hätte ich es “hinrotzen” sollen und im quick and dirty Verfahren eine Lösung bauen. Wenn das Feature dann ein Erfolg wird, wunderbar, dann machen wir es einfach neu oder setzen unser Optimierungsteam dran. Wenn es kein Erfolg wird: Abschalten.

Ja ich weiß, wenn es mal da ist, dann wird es auch genutzt und eure Produkt-Menschen werden sicher nicht wegwerfen, was schon da ist. Ich glaube, dass dies aber erstens eine Frage der Kommunikation ist und zweitens werden sie ganz schnell sehen, dass ihr Featuredurchsatz nach oben geht und die Dinge, die sich wirklich als erfolgreich herauskrsitalisiert haben eine bessere Qualität besitzen.  Schön war auch das Zitat von Kris “Wir haben jede Menge beschissenen Code da draußen, der uns reich macht”.

Nächstes Problem sind die Performance-Junkies. Das Tool muss irgendwann mal tausende von Usern abkönnen und deswegen brauchen wir Techologie X und es muss bis aufs kleinste optimiert sein. Am besten soll es auf einem Server laufen und und und. Bei mir ist es so, dass wir so viele Server im Betrieb haben, dass es kein Problem ist, wenn man noch mal welche hinzustellt. Was ich also sagen will. Wenn euer Tool/Feature im ersten Anlauf nicht viele User abkann, dann schlagt es mit Hardware tot. So teuer sind zwei Server in der Amazon-Cloud nicht, dass man sich das nicht leisten könnte.

Ich glaube, dass die Qualitätswelt mit einer solchen Vorgehensweise glücklich ist und auch die Entwickler, aber es bedeutet ein Umdenken im Prozess.

PS: Das ganze klappt nur bei Projekten und nicht bei Produkten. Sollte ich vielleicht noch zu dem Ansatz hinzufügen. Bei unseren redaktionellen Portalen wäre es ein Fortschritt.

Das eigentliche Problem ist, dass bei der Installation der Standardpakete nur eine ältere Version von PHPUnit zur Verfügung steht und sich verschiedene Funktionen im Framework geändert haben.

Warnung: Ihr verändert durch die Installation das System und tut das auf eigene Verantwortung!

Zunächst erstmal PHP und PEAR installieren, bzw. auf den neusten Stand bringen:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install -y php-pear php5-curl php5-xdebug
sudo pear channel-update pear.php.net
sudo pear upgrade-all

Nachdem das Upgrade durchgelaufen ist (kann eine Weile dauern), können wir dann PHPUnit installieren.

sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover components.ez.no
sudo pear channel-discover pear.symfony-project.com
sudo pear install --alldeps phpunit/PHPUnit

Zum Schluss prüfen wir noch schnell, ob wir wirklich die gewünschte Version installiert haben.

developer@developer:~$ phpunit --version
PHPUnit 3.5.15 by Sebastian Bergmann.

Nun dann, viel Spaß beim Testen!

Jetzt aber wieder zum eigentlichen Thema. Heute geht es um Qualitätsmanagement. Also nicht so richtig. Eigentlich geht es um einen Bestandteil der Entwicklungsprozesses. Vor einiger Zeit wurde ich zu einem Projekt hinzugerufen, in dem schon einiges im Argen war. Das Team hatte nicht mehr so viel Vertrauen in die Projektleitung, wie man sich das vielleicht wünschen würde. Als ich dann mit dem “Chefentwickler” geredet hatte, war die wichtigste Aussage “Unser größtes Problem ist, dass wir zu viele Probleme haben“.

Für die Entwickler war dies wirklich so. Jeder kannte mindestens vier große Probleme und jeder wusste, dass es damals ja auch noch viel mehr gab, an die man sich im Moment auch leider nicht erinnere. Was diese Probleme natürlich nicht löste. Ein ganz ungutes Gefühl Bauchgefühl schwingte bei diesem Projekt immer mit. Ein ordentliches Risikomanagement wurde bis dato auch nicht aufgesetzt.

Womit wir dann begonnen haben ist eine Bestandsaufnahme zu etablieren. Diese Aufnahme umfasste nur die Probleme. Wir sind also hingegangen und haben jeden aus dem Team interviewt. Am Ende hatten wir eine Excel-Tabelle zusammen mit allen bekannten Problemen und siehe da, es waren gar nicht so viele, wie gedacht. Und alleine dieses definitive Wissen um die Anzahl und Relevanz der Dinge, die momentan kritisch waren, gab dem Team ein gutes Gefühl. Auf einmal konnte man den Stand des Projektes besser einschätzen.

In unserem Fall haben wir diese Bestandsaufnahme zu einem festen Ritual gemacht. Einmal alle zwei Wochen sitzt jemand vom Qualitätsmanagement mit einem Entwickler zusammen und aktualisiert die Liste, die nun auch nach Relevanz sortiert ist. Probleme, dir gelöst wurden, werden ans Ende geschrieben und neue Punkte einsortiert.

Durch eine einfache Liste mit Problemen schafft man es das Bauchgefühl der Entwickler in wirkliche Fakten umzuwandeln. In den meisten Fällen, ist es nicht so schlimm, wie man glaubt. Wer ein richtiges Risikomanagement etablieren kann, ist natürlich besser beraten, aber in einigen Fällen fehlen dort sowohl Wissen, als auch Zeit.

Was ist aber eigentlich passiert? Für eine bestimmte Aufgabe musste ich Daten in der SimpleDB (Amazon Webservices) zwischengespeichern und dann an anderer Stelle weiter verarbeitet. Nun passiert es hin und wieder, dass meine Weiterleitung schneller als die Datenbank war und ich die Daten (noch) nicht lesen konnte.

Was macht man in diesem Fall? Abwarten, Tee trinken und nochmal probieren. In dem Fall kamen ein paar Zeilen Code dazu und alles lief wie gewünscht. Wirklich schick ist das jedoch so noch nicht.

Erstmal eine einfach Beipielklasse im PHP-Pseudocode zum besseren Verständnis:

<?php
class SomeWebResource
{
  public function load($key)
  {
    // do something
    return $data;
  }

  public function save($key, $data)
  {
    // do something
    return $flag;
  }

  public function delete($key)
  {
    // do something
    return $flag;
  }
}

In diesem Beispiel hat unsere Klasse drei Methoden, in denen die selben oder zumindest ähnliche Probleme auftreten können. Die Daten haben das falsche Format, der Webservice ist nicht erreichbar oder was auch immer.

Für diesen Fall bauen wir dann nun die Wiederholung ein.

<?php
class SomeWebResource
{
  public function load($key)
  {
    $count = 0;
    do {
      try {
        // do something
        return $data;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }

  public function save($key, $data)
  {
    $count = 0;
    do {
      try {
        // do something
        return $flag;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }

  public function delete($key)
  {
    $count = 0;
    do {
      try {
        // do something
        return $flag;
      } catch (Exception $e) {
        sleep(1);
      }
    } while (3 > $count++);
  }
}

Spontan sollten nun jedem mindestens drei Dinge auffallen. Der Code ist gleich um etliche Zeilen länger und wiederholt sich, man könnte fast ein Muster (Pattern) erkennen. Der Code ist nicht wirklich flexibel, wenn es darum geht die Wartezeit oder die Anzahl der Versuche zu konfigurieren. Der Code ist immer da und lässt sich so nicht mehr ohne die Wiederholung ausführen und es ist nicht die Aufgabe dieser Klasse die Wiederholungen zu kontrollieren.

In dem Fall schreit es doch gerade danach, diesen Code recyclebar auszulagern, findet ihr nicht?

Dafür brauchen wir nur eine einfache Proxy-Klasse. Ok, bevor jetzt jemand protestiert, dass sei doch garnicht das Proxy-Pattern, stimmt! Wir leiten die Proxy-Klasse nicht von der Klasse “SomeWebResource” ab und haben dadurch eine andere Schnittstelle. In diesem Fall ist das aber egal, denn wir leiten ja auch nur den Methodenaufruf weiter.

Nun aber erstmal die RetryProxy-Klasse:

<?php
class E7_Tools_RetryProxy
{
  // some other methods

  public function call($callback)
  {
    $exception = null;
    $count = 0;
    $args = func_get_args();
    array_shift($args);

    do {
      try {
        return call_user_func_array($callback, $args);
      } catch (Exception $e) {
        $exception = $e;
        sleep($this->getDelay());
      }
    } while ($this->getRepititions() > $count++);

    if ($exception instanceof Exception) {
      throw $exception;
    }
  }
}

Auch hier lässt sich natürlich das selbe Muster erkennen, aber wir haben es von jeder weitern Logik entkoppelt und die gewünschten Werte lassen sich nun einfach über die Setter einstellen.

Die Verwendung ist später ebenfalls einfach.

<?php
$proxy = new E7_Tools_RetryProxy();
$swr   = new SomeWebResource();
$data  = $proxy->call(array($swr, 'load'), 42);

Wer damit etwas experimentieren will, findet die komplette Klasse hier. Wie immer freue ich mich natürlich über möglichst zahlreiche Kommentare.