Software Entwicklung

Continuous Integration mit Jenkins

0

Am 17.Oktober zieht es mich zusammen mit Holger Rüprich nach Hamburg auf die web DevCon. Holger wird dort einen Vortrag zum Thema „Mobile Web Apps – Wie, Warum, Womit?” machen, den wir im Büro letzten Freitag schon hören durften.

Und auch ich werde dort einen Vortrag halten, und im Vergleich zu meinen letzten Talks wieder mal etwas technischer werden. Mein Vortrag behandelt das Thema Kontinuierliche Integration am Beispiel von Jenkins und PHP.

„Kontinuierliche Integration“ ist ein Prozess, der nach dem Einchecken von Code jedes Mal das komplette System neu erstellt. Selbst wenn eine Technologie keinen separaten Kompilierungsvorgang benötigt (etwa PHP), lohnt sich dennoch der Einsatz eines CI-Systems. Lassen sich doch so auch automatisiert Tests überprüfen und Fehler fallen besonders schnell auf. Jenkins ist einer der populärsten CI-Server und unterstützt zahlreiche Sprachen und Technologien wie Java, .NET oder PHP. Der Vortrag beschreibt Einrichtung und Einsatzmöglichkeiten von Jenkins und wartet mit vielen Tipps und Tricks direkt aus der Praxis auf.

Nachdem ich gerade erst von der WebTech Conference zurück bin, ist mein Plan, dieses Jahr mal alle Konferenzen links liegen zu lassen, irgendwie nicht aufgegangen.

PHP World Kongress 2010

0

PHP World Kongress 2010 - SpeakerWie schon letztes Jahr werde ich auch dieses Jahr wieder als Speaker auf dem PHP World Kongress vom 09.11. bis 11.11. in München vertreten sein. Dieses Jahr ist nicht nur Holger Rüprich wieder dabei (um wieder mit mir zusammen einen Workshop zu veranstalten), sondern auch Nico Steiner wird zum ersten Mal auf dem PHP World Kongress dabei sein und einen Vortrag zu Frontend-Performance zu halten. Nico ist Experte für Frontend-Technologien und -Architektur in meiner Abteilung bei der 1&1 Internet AG. Meine Session am ersten Tag der Konferenz steht dieses Jahr unter dem Motto „Der erfolgreiche Programmierer”, wie bereits letztes Jahr wird es weniger um PHP-Code und dafür mehr um persönliche Entwicklung und Zusammenarbeit gehen.

Was macht einen Programmierer erfolgreich? Nicht nur fachliche Kompetenz und eingesetzte Methodologien sind verantwortlich. Dazu gehören auch Soft Skills, die Wahl eines geeigneten Mentors, das Verfolgen einer eigenen Version und vieles mehr. Erfolgreiche Programmierer sind leidenschaftlich, pragmatisch und produktiv – dieser Vortrag zeigt, warum.

Am zweiten Tag laden Holger und ich dann zum dreistündigen Workshop mit dem Thema „PHP im Unternehmenseinsatz” ein, in dem wir einen Überblick über die aus unserer Sicht wichtigen Bereiche für die Erstellung unternehmenskritischer Applikationen geben.

PHP wird heutzutage fast schon selbstverständlich im professionellen Bereich eingesetzt. Doch auch die verwendeten Tools und Methodologien müssen professionellen Ansprüchen genügen. Dieser Workshop zeigt direkt wie PHP in großen Projekten eingesetzt wird und wirft einen Blick auf die Themen verwendete Methodologien, Software, Build-System, Projektmanagement, Teamführung und weitere Aspekte.

Die nächsten zwei Wochen werde ich jetzt nutzen, die Folien mit dem letzten Feinschliff zu versehen.

Webinale / IPC 2010 in Berlin

0

Eine PHP Konferenz in Berlin war für mich die ideale Kombination, endlich mal wieder meinen Koffer zu packen, in einen Zug zu sitzen und mich vier Tage in einem Hotel mit einer Menge Entwickler aufzuhalten.

Berlin fand ich spitze, aber da das hier kein Blog über Städtereisen ist, schreibe ich heute „nur” eine kurze Zusammenfassung dessen, was ich mit Nico und Frank auf der International PHP Conference Spring Edition 2010 und der Webinale 2010 erlebt und gelernt habe.

Die Workshops

Begonnen hat die Konferenz für mich mit einem Workshop am Sonntag nachmittag (morgens hatten wir eine Stadtrundfahrt, aber dazu wollte ich ja hier nichts schreiben). Der Workshop „Softwarearchitektur vs PHP” von Johann-Peter Hartmann war sehr unterhaltsam und mit der Vorstellung von ATAM (Architecture Tradeoff Analysis Method) habe ich auch etwas neues gelernt. Ich hatte zwar mit etwas mehr Inhalten zum Thema Architektur gerechnet und hätte auf den interaktiven Teil auch verzichten können, aber alles in allem war es ein interessanter Vortrag.

Montag

Der Montag startet mit zwei eher durchwachsenen Keynotes: Während der Vortrag „Die Mensch-Maschine-Beziehung und ihre Folgen” von Ibrahim Evsan unterhaltsam war, obwohl er nichts Neues erzählt hatte, war die Google-Keynote „Die Zukunft liegt in der Cloud” einfach nur langweilig. Der Gipfel war, dass Petra Sonnenberg zeigen wollte, wie in Zukunft alle unsere Applikationen in der Cloud laufen, gleichzeitig aber eine Präsentation mit Google Docs erstellt hatte, die aussah wie die ersten Gehversuche mit Power Point. Geendet hat die Keynote mit einem Werbevideo von Google. Nicht gerade das, was ich mir von einem Unternehmen wie Google versprochen hatte.

Danach kam das Highlight des Tages: Julian Koschwitz hat in seiner Session zu „Augmented Editorial Design” gezeigt, wie man klassische Printmedien mit dem Web verbinden kann und Magazine um dynamischen Content wie Videos oder Sound anreichern kann. Eine Webcam und ein Browser ist ausreichend. Ähnlich gut war die erste Session der IPC, die ich danach besucht habe. David Soria Parra hat sehr anschaulich dargestellt, wie „Git für Fortgeschrittene” Probleme beseitigt, die viele von uns mittlerweile mit Subversion haben.

Nachmittags ging es mit einem Vortrag zu „Continuous Integration und Continuous Deployment” von Manuel Pichler weiter, von dem ich mir auch mehr erhofft hatte. Manuel hat die zwar Bewegründe für CI und wie man es schrittweise einführt schön zusammengefasst, der Teil über Deployment ist leider sehr kurz ausgefallen und war für mich leider nicht hilfreich, da wir täglich und nicht nur wöchentlich deployen.

Abgeschlossen habe ich den Tag mit der für mich langweiligsten Session der Webinale: „Positive User Experience durch User Centered Web Design”. Meine Experience war in diesem Vortrag nicht sehr positiv, was zum Teil auch an der fortgeschrittenen Uhrzeit gelegen haben mag.

Dienstag

Der Dienstag morgen begann mit einem Vortrag zu „Frontend Performance mit PHP” von Frank und Nico, der sehr gut besucht war und mir auch noch ein paar neue Impulse gegeben hat, obwohl ich natürlich wußte, was auf mich zu kommt.

Da sich Jung von Matt für die aktuelle 1&1 Kampagne verantwortlich zeigt, habe ich mir danach die Session „Künftig entscheidend für den Erfolg (fast) jeder Marke: Produktinfo und -inszenierung” von Michael Behrens angeschaut. Die Beispiele, die er gezeigt hat, waren interessant, jedoch weit weg von dem, was JvM für 1&1 macht. Deutlich cooler waren auch die Beispiele, die Michael Chaize in seiner Session „Ten Innovative Projects for the Flash Platform” gezeigt hat. Von 3D-Grafiken über Gesichtserkennung bis hin zur Emulation von Spielekonsolen war da für jeden was dabei. Flash scheint (leider) trotz HTML5 immer noch nicht tot zu sein.

Durch das ständige Vertauschen von Sessions habe ich leider mittags einige Sessions verpasst und die Zeit genutzt, was für’s Büro zu programmieren. Abgeschlossen habe ich den Tag mit einer spontanen Session zu YQL von Yahoo!, in der leider nur die Standard-Beispiele gezeigt wurden.

Mittwoch

Den Mittwoch habe ich nach dem Hotel-Checkout wieder mit zwei Keynotes auf der Webinale begonnen. David Carr hat in seiner Keynote „The Speed of Now” den Namen zum Programm gemacht und ist extrem schnell durch eine Masse an Slides gegangen, so dass man ihm kaum noch folgen konnte. Ossi Urchs Keynote „Social Web oder Die neue Macht der Nutzer” klang eher nach einer Keynote von 2008 als nach einer Keynote in der man Trends für 2011 erfahren hätte. Das allgegenwärtige „Twitter, Facebook und Smartphones beherrschen unser Leben!” wurde am dritten Tag der Webinale dann doch etwas alt.

Danach fand die Panel Diskussion „Holy Code, holy Shit! – Die Developer-Designer-Hölle” statt, an der ich auch beteiligt war. Leider war es organisatorisch nicht möglich, dass sich alle Teilnehmer vorher treffen, so dass hier keine wirkliche Diskussion entstand und es eher bei „Thema verfehlt” einzuordnen war. Sollte ich jemals wieder an einer Panel-Diskussion teilnehmen, dann nur, wenn es vorher auch möglich ist, sich mit den anderen Teilnehmern und vor allem dem Moderator abzustimmen.

Nach der Mittagspause war ich dann mit meinem Vortrag „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” dran.

Der Vortrag lief gut, ich habe mir auch meinen „Cowboy/Indianer”-Witz merken können und das Feedback war durchweg positiv. Abgeschlossen habe ich den Tag mit einem Vortrag von Frank zum Thema „A better Approach for File System dependent tests”, in dem Frank sein Projekt vfsStream vorgestellt hat.

Zusammenfassend hat sich der Besuch der Konferenzen für mich mehr gelohnt, als das in den letzten Jahren der Fall war. Tatsächlich habe ich während der Konferenz jedoch festgestellt, dass mich die Themen der Webinale mittlerweile mehr fesseln als die Sessions auf der PHP Conference.

Kleine Schritte sind besser als keine Schritte

1

Eigentlich hatte unter diesem Titel geplant, einen Eintrag über die Pfadfinder-Regel zu schreiben, die Robert C. „Uncle Bob” Martin in seinem Buch Clean Code vorstellt:

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Hip Hop Not For PHP

0

Da im Moment jeder einen Blog-Eintrag zu HipHop schreibt, kann ich mich da natürlich nicht rausnehmen und blogge bei der Gelegenheit mal eines meiner Lieblings-Hip-Hop-Videos:

Streng genommen ist das ja wahrscheinlich noch nicht mal Hip Hop sondern Rap. Und ein Hip Hop Fan bin ich eigentlich auch nicht.

Falls jemand meine Meinung zu HipHop For PHP hören möchte, ist die ganz einfach:

Facebook hatte ein Problem, Facebook hat das Problem gelöst. Jetzt stellt Facebook die Lösung noch jedem zur Verfügung, der sie nutzen möchte. So funktioniert Open Source. Also ist alles bestens.

Ich werde es wohl nicht nutzen, ich hab’ andere Probleme als Facebook.

Verwenden Sie keine Verneinung nicht!

3

Wenn ich es schaffe, eine if-Anweisung zu vermeiden, dann versüßt mir das immer meinen Tag. Aber leider kann man als Entwickler nicht darauf verzichten, Bedingungen in den Code einzubauen.

Was ich jedoch versuche, an allen Stellen zu vermeiden, ist der schreckliche „not”-Operator, der in den meisten Sprachen durch den Einsatz von „!” implementiert wird. Der Einsatz dieses Operators macht den Quellcode immer schwerer zu lesen. Ich möchte keine Bedingungen wie die folgende in meinem Code haben:

if (!$this->isUserAuthenticated()) {
    $this->requireLogin();
}

So ein kleines Ausrufezeichen übersieht man einfach viel zu leicht und da es die Logik des Ausdrucks komplett umdreht, ist es einfach viel zu wichtig, um übersehen zu werden. Noch schlimmer wird es, wenn Sie den Operator mehrfach in einer Bedingung einsetzen.

if (!$this->isUserAuthenticated() && !$this->isInternalIP()) {
    $this->requireLogin();
}

In solchen Code-Stellen kommt es gerne auch mal vor, dass man UND mit ODER verwechselt. Denn wenn man etwas negieren möchte, sollte man dran denken, auch die Verknüpfung zu negieren oder entsprechend zu klammern. Die obige Bedingung ist mit der folgenden identisch, statt einem logischen UND verwenden Sie jedoch ein logisches ODER:

if (!($this->isUserAuthenticated() || $this->isInternalIP())) {
    $this->requireLogin();
}

Auf den ersten Blick erschließt sich mir nie, was die Bedingung aussagt, sobald ein „not”-Operator im Spiel ist.

Aber welche Möglichkeiten gibt es, um den ungeliebten Operator loszuwerden?

Verneinen Sie den Methodennamen

Statt einer Methode isUserAuthenticated() einen „not”-Operator voranzustellen, könnten Sie eine zweite Methode implementieren, die bereits auf das Gegenteil prüft und einen sprechenden Namen hat:

if ($this->isUserUnknown()) {
    $this->requireLogin();
}

So liest sich der gesamte Code viel flüssiger und es kann nicht dazu kommen, dass der Operator übersehen wird oder das Ergebis im Kopf evaluiert werden muss.

Prüfen Sie auf false

Statt den „not”-Operator zu verwenden, können Sie die Rückgabe der Methode auf false prüfen:

if (false === $this->isUserAuthenticated()) {
    $this->requireLogin();
}

Der Code ist zwar nicht so lesbar wie im vorherigen Beispiel, aber wenn Sie die Bedingung nur einmal prüfen müssen, kann es sinnvoll sein, auf die Implementierung einer Methode für diesen einen Fall zu verzichten. Achten Sie übrigens immer darauf, bei einer Bedingung den konstanten Wert auf der linken Seite der Klammer zu setzen. Sollten Sie zu wenige Gleichheitszeichen verwenden, so kann aus der Bedingung nicht aus Versehen eine Zuweisung werden.

Verwenden Sie unless

Sollten Sie Ruby verwenden, so haben Sie noch eine dritte, sehr elegante Möglichkeit. Ruby bietet Ihnen neben der if-Anweisung auch eine unless-Anweisung, die, wenn Sie sie als Modifier einsetzen, besonders elegant zu lesen ist.

require_authentication unless user_is_authenticated

In diesem Beispiel ist der Code kaum noch von einem englischen Satz zu unterscheiden. Unterstützt wird das natürlich noch dadurch, dass Sie in Ruby keine Klammern verwenden müssen, wenn Sie keine Parameter an eine Methode übergeben wollen.

Wenn Sie also das nächste Mal eine Bedingung negieren, dann denken Sie darüber nach, ob es keine bessere Lösung gibt. Und falls Sie in einer Bedingung zweimal negieren müssen, dann denken Sie nochmal über eine Alternative nach. Es gibt sie sicher.

Ruby on Rails on Windows

3

Nachdem ich Anfang des Jahres beschlossen hatte, Ruby zu lernen, habe ich das vor einer Woche in die Tat umgesetzt. Zusammen mit Holger entwickle ich eine webbasierte DVD- und Blu-Ray Verwaltung basierend auf Ruby on Rails. Dabei habe ich den Fehler gemacht, dass ich das auf einem Windows-Notebook machen wollte und erst mal fast einen Abend mit der Installation der neusten Ruby Version 1.8.7 verbracht.

Damit das anderen nicht auch so geht, versuche ich nochmal, zu rekapitulieren, welche Schritte dazu nötig waren:

  1. Laden Sie den Ruby One-Click Installer 1.8.6 von der Ruby Website herunter.
  2. Installieren Sie Ruby 1.8.6 (zum Beispiel in C:ruby).
  3. Laden Sie das Ruby 1.8.7 Binary von der Ruby Website herunter.
  4. Entpacken Sie das Binary in den selben Ordner (C:ruby), in den der Installer die Version 1.8.6 installiert hat.
  5. Laden Sie ZLib Packages von der ZLib Website herunter und Entpacken Sie das Archiv.
  6. Benennen Sie die Datei zlib1.dll nach zlib.dll um.
  7. Kopieren Sie die Datei zlib.dll nach C:rubybin.
  8. Laden Sie libiconv 1.91 herunter und Entpacken das Archiv.
  9. Kopieren Sie die Datei bin/iconv.dll nach C:rubybin.
  10. Laden Sie OpenSSL herunter und installieren es. Bei der Installation kann es sein, dass Sie aufgefordert werden, zuerst das Microsoft Visual C++ 2008 Redistributable Package zu installieren.

Damit sollte Ruby installiert sein. Überprüfen können Sie das einfach in der Konsole über:

C:Usersschst> ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32]

Um Ruby on Rails zu verwenden, sollten Sie nun auch noch SQLite installieren. Während der Entwicklung können Sie Ihre Models sehr komfortabel in einer SQLite Datenbank persistieren. Sollten Sie SQLite noch nicht installiert haben, reichen dazu die folgenden Schritte aus:

  1. Laden Sie die vorkompilierte Verson für Windows herunter.
  2. Entpacken Sie das Archiv
  3. Kopieren Sie die Datei sqlite3.exe nach C:rubybin.

Als nächstes können Sie sich nun daran machen, den gem Installer für Ruby zu installieren:

  1. Laden Sie die aktuelle Version von RubyForge herunter.
  2. Entpacken Sie das Archiv.
  3. Führen Sie ruby setup.rb aus.

Alle weiteren Schritte erledigt nun gem für Sie:

C:Usersschst>gem install rails
C:Usersschst>gem install sqlite3-ruby

Danach können Sie mit Ihrer ersten Ruby on Rails Applikation loslegen:

C:Usersschst> rails my-app
C:Usersschst>     cd my-app
C:Usersschst>     ruby script/server

Ihre Anwendung öffnen Sie nun im Browser über http://localhost:3000.

23 Dinge #0: Menschen

0

Bevor ich über 23 Dinge blogge, möchte ich noch einen Artikel voran stellen, der die folgenden Artikel meiner Serie in einen entsprechenden Kontext setzt. Sie bekommen hier sozusagen einen Tipp, wie Sie die folgenden Tipps anwenden sollten.

Beginnen möchte ich mit einem Yogiism von Dale „Yogi” Berra, einem der erfolgreichsten Baseball-Spieler der US-Major League:

„In theory, there is no difference between theory and practice. In practice, there is.”

Frei übersetzt bedeutet dies so viel wie:

„In der Theorie sind Theorie und Praxis das selbe, in der Praxis sind sie es nicht.”

Meine 23 Dinge, die Sie über Software-Entwicklung ins Teams wissen sollten, entspringen zwar meiner praktischen Erfahrung, aber in diesem Blog werden sie auf Theorien reduziert. Die Tipps haben mir in den Teams, in denen ich bereits gearbeitet habe (sowohl in geschäftlichen, als auch im Open Source Umfeld), wertvolle Dienste geleistet. Das bedeutet jedoch nicht zwangsläufig, dass diese Tipps sklavisch bei Ihnen angewendet werden sollten. Manche Tipps müssen vielleicht an ihr Umfeld angepasst werden, andere funktionieren in Ihrem Umfeld überhaupt nicht.

Sobald Sie von Teamarbeit sprechen, sollten Sie nicht vergessen, dass es dabei auch immer um Menschen geht. Die Menschen sollten immer im Mittelpunkt Ihrer Bemühungen stehen, denn sie sind es, die Ihr Team formen und am Ende die Software produzieren.

Und Menschen sind nun mal verschieden. Also sind auch Teams verschieden und werden nicht genau gleich auf die Tipps in dieser Artikelserie reagieren. Achten Sie also beim Umsetzen der Tipps darauf, dass Ihnen nicht der Fehler auf diesem Poster passiert:

Conformity - It's the one who is different, that get's left out in the cold.

Schätzen Sie die Unterschiedlichkeit Ihres Teams und wenn ein Tipp nicht zu Ihnen oder Ihrem Team passt, dann passen Sie ihn an. Dieses Poster hängt im Büro übrigens auch in DIN A1 an meiner Wand, um mich und andere jeden Tag daran zu erinnern.

Commercial Break: PHP Design Patterns

0

Die zweite Auflage meines Buches ist mittlerweile zwar fast schon ein Jahr alt, aber trotzdem darf natürlich ein bißchen Eigenwerbung in meinem Blog nicht fehlen.

PHP Design Patterns” ist das erste deutschsprachige Buch zu Entwurfmustern in PHP. Neben einer Einführung in objektorientierte Programmierung im Allgemeinen und mit PHP im besonderen (Kapitel 1) sowie einem kurzen Ausflug in die SPL (Kapitel 2), zeigt das Buch auf grundlegende Regeln für gutes Software Design wie z.B. „Vererbung sorgt für starre Stukturen. Verwenden Sie stattdessen Objektkomposition, um verschiedene Funktionen einfacher miteinander kombinieren zu können.” Kapitel 3 behandelt weiterhin auch Fluent Interfaces und Dependency Injection, samt der Verwendung des DI-Containers in Stubbles.

Kapitel 4,5 und 6 behandeln dann einige der Standard Gang of Four Entwurfsmuster, wie Abstract Factory, Prototype, Composite, Facade, Flyweight, Command, State oder auch Chain-of-Responsibility. Die letzten beiden Kapitel stellen das Schichtenmodell vor und zeigen, wie man dies mit Hilfe eines Model-View-Controllers und Patterns wie Active-Record, Template-View, Registry oder auch Event-Dispatcher implementiert.

Das PHP Magazin schreibt zur ersten Auflage (1/2007):

Ein rundes, das anvisierte Themengebiet hervorragend ausfüllendes Buch, das vom Leser nur eins verlangt: Zeit und Konzentration auf den Inhalt. Der Lohn dieser geringfügigen Investition sind verschiedenste Aha-Effekte und ein echter Schub an neuen Kenntnissen und Ideen. Und ein Nachschlagewerk, das man nach dem ersten Lesen nicht mehr vom Schreibtisch nehmen möchte.

Das Buch wurde für die zweite Auflage komplett überarbeitet und an PHP 5.3 angepasst. Dabei wurde ein Großteil der Kapitel erweitert:

Details zu Buch:

In case of emergency…

0

Entwickler sind Menschen. Fehler passieren. Und wenn Entwicklern ein Fehler passiert, dann nennt man das Bug.

Das in einem Projekt nach dem Release nochmal Bugs auftreten, ist nicht wahrscheinlich, es ist absolut sicher. Meist haben diese Bugs dann eine (negative) finanzielle Auswirkung, oder zumindest ist das die Vermutung des Kunden. Der Kunde befürchtet einen Verdienstausfall, der natürlich so kurz wie möglich gehalten werden muss; und das rationale Denken beim Kunden, Manager und Entwickler setzt leider allzu häufig aus.

Die pragmatischen Programmierer Andrew Hunt und David Thomas haben einige Tipps, wie man sich bei der Fehlersuche verhalten sollte:

Lösen Sie das Problem, nicht die Schuldfrage.

Der Bug ist bereits aufgetreten, es wird Ihnen jetzt nichts helfen, wenn Sie wissen, wer Schuld daran ist. Leider ist es oft viel einfacher, rauszufinden, wer schuld ist, als rauszufinden, wie der Bug gefixt werden kann. Deshalb tendieren viele Menschen eher zur ersten Alternative. Was man dagegen tun kann, habe ich bereits in „Denk positiv!” geschrieben.

Wenn Sie auf Grund von Verträgen oder SLAs wissen müssen, wer die Schuld trägt, so ist für die Klärung dieser Frage nach Beseitigung des Fehlers noch genug Zeit.

Keine Panik!

Wenn man so schnell wie möglich versucht, den Bug zu fixen, ohne genauer darüber nachzudenken, ist die Gefahr groß, dass weitere Bugs ins System eingeführt werden, während einer behoben wird. Und natürlich fügen diese Bugs Ihrem Kunden meist einen noch größeren Schaden zu, als der ursprüngliche Bug.

Das absolute Highlight ist, dass in solchen Situationen gerne auch die Unit-Tests (die Folgefehler entdeckt hätten) vor dem Deployment übersprungen werden, um den Fix möglichst schnell live zu bekommen. Näher werden Sie Kamikaze in Ihrem Leben wahrscheinlich nicht kommen. Ich selbst war leider schon so nahe dran.

Bleiben Sie also ruhig und stellen Sie sicher, dass Sie eine saubere Entwicklunsumgebung haben, bevor Sie mit dem Bugfixing beginnen. Fixen Sie den Bug also nicht in einem lokalen Checkout, der Modifikationen enthält, die noch nicht deployed wurden.

Wenn Sie Hufabdrücke sehen, sollten Sie an Pferde denken, nicht an Zebras.

Wenn ein Fehler auftritt, nachdem Sie den Code geändert haben, dann ist es wahrscheinlich, dass Ihre Änderung den Fehler verursacht hat. Suchen Sie also dort. Entwickler sind gerne der Ansicht, dass die letzte Änderung so marginal war, dass sie keinen Fehler verursacht haben kann. „Sicher muss es ein Problem im Kernel sein, dass nur Donnerstags bei Regen auftritt und deshalb nicht entdeckt wurde.” Sehr wahrscheinlich ist das nicht das Problem, sondern die marginale Änderung war der Auslöser.

(Die einzige Ausnahme von dieser Regel ist, wenn Sie mit Destrukturen in PHP arbeiten, hier habe ich schon Phänomene erlebt, die nur von Scully und Mulder gelöst werden können. Beim Einsatz von Destruktoren in PHP gilt also – Trust No One.)

Nicht annehmen, sondern beweisen.

Obwohl ein Bug einem Entwickler beweist, dass er nicht unfehlbar ist, verhält man sich oft weiterhin so, als wäre man unfehlbar. Ein Entwickler nimmt dann bei der Fehlersuche einfach an, dass eine bestimmte Methode auf jeden Fall fehlerfrei funktioniert und überspringt diese beim Debuggen. Tun Sie das nicht. Prüfen Sie jede kleine Eventualität, jede noch so einfache Methode und beweisen Sie, das diese mit den Eingaben, die produktiv zu einem Fehler führen, korrekt arbeitet. Auch dieses Thema hatte ich bereits in „Don’t assume!” tiefergehend diskutiert.

Wenn Sie diese einfachen Regeln befolgen, dann haben Sie beim nächsten Bug deutlich höhere Chancen, diesen schnell, nachhaltig und ohne Folgefehler zu beseitigen.

nach oben