Upgrade your LAMP Stack to 2013
Kommentare

Linux, Apache, MySQL, PHP – dieser Technologie-Stack aus Open-Source-Komponenten ist unter dem Akronym LAMP in die IT-Geschichte eingegangen. Doch kommt man mit reinem LAMP heute noch zu modernen Webanwendungen,

Linux, Apache, MySQL, PHP – dieser Technologie-Stack aus Open-Source-Komponenten ist unter dem Akronym LAMP in die IT-Geschichte eingegangen. Doch kommt man mit reinem LAMP heute noch zu modernen Webanwendungen, die den Anforderungen an Sicherheit, Performance und Skalierbarkeit genügen? Nein, meinte Arne Blankerts von thePHP.cc in seiner IPC Session „Upgrade your LAMP Stack to 2013“, und zeigte Wege auf, wie man seine LAMP-Anwendung für das Jahr 2013 fit bekommt. 

Unter dem Motto „Es muss nicht immer Apache sein“ führte Arne das Projekt Nginx ein. Nginx, sprich „Engine X“, ist ein Webserver, der Reverse Proxy und E-Mail-Proxy-Funktionen enthält, Load Balancing unterstützt und bereits in vielen prominenten Services wie wordpress.com und GitHub zum Einsatz kommt. Mit Nginx lässt sich dynamischer HTTP Content über einen asynchronen, ereignisgetriebenen Ansatz deployen. In Zusammenhang mit dem Load Balancer erreicht man eine besser vorhersehbare Performance unter hohen Lasten.

Aus LAMP wird dann sozusagen LNMP – oder, weil das niemand aussprechen mag, LEMP. Doch bleibt das Modernisierungskarussell hier nicht stehen. Arne rät zum Einsatz des FastCGI Process Manager (FPM), ein Protokoll für die

Einbindung externer, dynamischer Anwendungen in einen Webserver. Zudem bieten Keyvalue-Stores wie Redis oder memcached für die meisten Zwecke den Ersatz für langsame MySQL-Datenbanken. Steht genügend RAM zur Verfügung, sind Key-Value-Stores in Sachen Performance und Skalierbarkeit fast unschlagbar.

Bei dem modernisierten Technologie-Stack sollten wir indes nicht stehen bleiben. Und so rief thePHP.cc-Kollege Sebastian Bergmann zum ausgiebigen Testen mit PHPUnit auf. Denn leider sieht die Realität in vielen Fällen noch so aus, dass in PHP-Entwicklerstuben zu wenig Zeit in professionelles Testen investiert wird.

Das liegt aber nicht unbedingt an der Unbedachtsamkeit der Entwickler. Sebastians Erfahrung nach gibt es vor allem auch Widerstände auf der Management-Ebene zu überwinden, in der nicht immer eingesehen wird, warum man Entwickler für etwas anderes als das Entwickeln bezahlen sollte.

Eine Strategie ist hier der kalkulierte Ungehorsam: es einfach niemandem sagen, dass man einen gewissen Stundensatz allein für das Testen aufwendet. Langfristig geht es allerdings darum, das Management von der Notwendigkeit des Testens zu überzeugen.

Wie dem auch sei – wer zum ersten Mal mit PHPUnit arbeitet, sollte sich nicht von den recht hohen Anfangshürden abschrecken lassen. Denn tatsächlich kann ein Anwender überwältigt sein von den unzähligen Features und dem Labyrinth an technischen Begriffen, angefangen bei Edge-to-Edge-Test über End-to-End-Test bis zu den Akzeptanztests, Systemtests und den funktionalen Tests. Hier sollte man Ruhe bewahren und der Aussage Bergmanns trauen: Im Grunde genügt es, zum Starten zwei bis drei PHPUnit-Grundkonzepte zu verstehen. Der Rest ist historisch gewachsener Zuckerguss, der meist nur Sonderfälle behandelt.

Doch das vielleicht größte Problem beim Testen liegt darin, dass sich viele Code-Basen nicht gut zum Testen eignen – wer schreibt schon zu 100% Clean Code? Wenn Sie also gerne globale Konstanten verwenden, wilde Abhängigkeiten einbauen, Datenbankzugriffe in der Modell-Schicht tätigen und Prints nicht nur in der View verwenden (Stichwort: Separation of Concerns), dann wundern Sie sich nicht, wenn Sie auch mit dem Testen Probleme bekommen.

Zwar bieten Workarounds aus dem Schatz der PHP Test Helpers eine gewisse Flexibilität – doch lenken diese „beyond dirty“ Tricks vom eigentlichen Problem der schlechten Codebasis ab.

Einige Tipps vom Meister:
  • Vermeide die „Global Static Hell“
  • Nutze Dependency Injection und lose Koppelung
  • Schreibe kurze Methoden mit maximale 10-20 logischen Codezeilen
  • Praktiziere, wenn möglich, Test First Development
  • Geht dies nicht, warte nicht zu lange mit dem Schreiben der Tests (nicht erst eine Woche nachher!)
  • Wenn du Tricks anwenden musst, ist dies ein Indiz für unsauberen Code. Investiere lieber Zeit in Refactorings.
  • Denn mit Clean Code ist auch die Nutzung von PHPUnit kinderleicht.

Und mit dem Grundsatz des Google-Entwicklers Miško Hevery schickte Bergmann uns in die nächsten IPC Sessions:

„Das Geheimnis des Testens liegt im Schreiben von testbarem Code“

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -