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.