Der Product-Backlog ist eines der wichtigsten Artefakte im Scrum-Prozess und wohl eines der am meisten unterschätzten zugleich.
In ihm sammeln sich alle Ideen, alle Anforderungen und Gedankenblitze, die der Kunde oder auch der Entwickler beim Arbeiten mit einem Produkt haben. READ MORE
So kurz vor Weihnachten will ich mich einem Thema widmen, das zum Daily Business von uns Entwicklern zählt: Bugfixing!
Womit wir Entwickler uns schnell abfinden sollten, ist: Fehler macht jeder. Perfektionisten haben es in unserem Beruf schwer. Zwar gibt es ausgeklügelte Qualitätssicherungsstrategien, aber auch die können nicht jeden Fehler aufdecken. Den Zeigefinger sollte sich daher ein Entwickler am besten gar nicht erst angewöhnen, sonst hat er bald sehr viele Zeigefinger auf sich selbst gerichtet. Daher mag ich den Teamgedanken aus Scrum sehr. Dort wird ein Bug gemeldet und das Team kümmert sich darum. Von wem der Bug stammt, spielt dabei keine Rolle.
Wir sagen es am besten nochmals alle gemeinsam: Wir machen Fehler! Befreiend, nicht? Und wir machen dies sicher nicht mit Absicht. Fehler kommen einfach vor. Abhängig von der Tagesform, den Anzahl Unterbrechungen bei der Arbeit, dem heutigen Horoskop, egal, es lassen sich nicht alle vermeiden, aber die schlimmsten mit einem guten Testing und QS im Vorfeld finden.
Ich erkläre meinen Nachbarn gern, dass ich für meine Arbeit ausreichend Schlaf brauche, wenn diese mal wieder nachts waschen oder mit Möbeln jonglieren. Nicht, weil ich sensible Maschinen bediene oder Arzt bin, sondern weil meine Arbeit einfach eine hohe Konzentration erfordert und ohne diese sich mehr Fehler einschleichen. Das beeindruckt meine Nachbarn jetzt nicht wahnsinnig. Da hilft der Hinweis, dass ich alles Mögliche programmiere, vielleicht ihre nächste Waschmaschine oder ihr Auto.
Als nebenberuflicher Autor springt mir die Nähe von Bugfixing zu Krimis praktisch täglich ins Auge.
Wenn mir ein Bug gemeldet wird, komme ich als Kommissar an den Tatort. Im ersten Moment gilt es, anhand des Tatorts Indizien zu sammeln, die den Kreis der Verdächtigen einschränken. Das kann ganz im Sinne von Sherlock durch kognitive Schlussfolgerungen geschehen oder mit CSI Methoden. Ich persönlich fühle mich Sherlock näher, da unser Hauptinstrument der Verstand bleibt, auch wenn wir unser persönliches Labor (Debugging Umgebung, Dumps, etc.) zur Verfügung haben.
Wenn der Tatort gesichert ist, kann der Kommissar die Hintergründe des Opfers miteinbeziehen, persönliche Situation, Beziehungen, Feinde. In unserem Fall sind das die beteiligten Klassen und Methoden, Frameworks, Laufzeitumgebung.
Jetzt gibt es verschiedene Vorgehensmodelle, von denen ich zwei sehr allgemeine sehr häufig anwende. Die Vorgehen sind davon abhängig, welcher Art der Fehler ist. Wenn ich eine schöne Fehlermeldung – sprich eine Exception mit Stacktrace und allem Pipapo – habe, kenne ich zumindest schon die Mordwaffe und den Tatort. Daher beginne ich beim Tatort und verfolge den Weg des Opfers zurück.
1) Die Spur (zurück-)verfolgen
Wer kennt das noch von früher? Messageboxen einbauen, um zu sehen, ob der entsprechende Code überhaupt durchlaufen wird? Debugging ist heute die elegantere Art, den Weg abzuschreiten. Dank Breakpoints und Step by Step Debugging lässt sich der Weg bis zum Opfer leicht nachvollziehen und die Ursache des Fehlers ist meist schnell gefunden.
Einzig bei Javascript Fehlern, pflasterte ich den Weg noch lange mit Alerts, zum Glück lässt sich das heute ebenfalls debuggen, dank Visual Studio und den neuen Browsern (im IE integriert, in Firefox durch FireBug).
Ich kenne keine Statistiken, aber ich bin mir ziemlich sicher, dass die Null Reference Exception, die mit Abstand häufigste ist. Die liesse sich an sich gut umgehen. Vor jedem Zugriff auf ein Objekt, eine if-Abfrage vorschalten.
Manchmal wurde das Opfer jedoch ganz woanders um die Ecke gebracht und nur am vermeintlichen Tatort, sprich dem Fundort abgeladen, von der Tatwaffe keine Spur. Dies ist der Fall, wenn keine Fehlermeldung auftritt. Ich hatte gerade so einen Fall, da liess sich ein Formular in allen Browsern speichern, bloss in Firefox nicht. Das Formular wurde ganz normal abgeschickt (sichtbarer Postback durch das Neuladen der Seite), aber die Daten blieben unverändert. Der Fehler trat erst seit dem neuen Design auf. Für mich gab es also zwei mögliche Szenarien: Entweder war das neue Control Schuld oder die neue Umgebung. Also habe ich das neue Control in die alte Umgebung eingebaut. Funktionierte wunderbar, auch in Firefox. Das alte Control in der neuen Umgebung verursachte denselben Fehler. Die Masterpage war recht gross mit vielen Javascripts, Controls und Css. Das bringt mich zum:
2) Ausschlussverfahren
Bei dieser Methode werfe ich alles der Reihe nach raus, bis der Fehler nicht mehr auftritt. Meist heisst das, dass ich einfach keinen Schimmer einer Ahnung habe, was die Tatwaffe, der Tatort, geschweige denn das Motiv ist. Mutmassungen und ein gutes Bauchgefühl, das sich meist aus der Erfahrung und der geschärften Intuition eines Sherlocks ergibt, helfen weiter. Methodik ist auch in diesem Verfahren angesagt, denn wenn ich zu viel rauswerfe, so dass gar nichts mehr funktioniert, finde ich den Fehler bestimmt nicht.
Im Falle meines Firefox Bugs habe ich die Masterpage soweit „ausgezogen“, bis nur noch das Formular Control, Javascripts und Css darauf zu finden waren. Als auch das Javascript rausflog, speicherte auf einmal auch der Firefox wieder. Aha! Tatwaffe gefunden. Das hätte ich mir gleich denken können (wo war da die geschärfte Intuition?). Also beginne ich beim Javascript-File wieder von vorn und schmeisse einfach von Beginn weg alles Stück für Stück raus, bis der Firefox speichert und ich den Tatort ebenfalls gefunden habe. Mit Tatwaffe und Tatort ist das Motiv schnell gefunden, mit dem sich auf den Täter rückschliessen lässt. Der Täter ist für uns jedoch gar nicht so wichtig, denn das wäre ja wieder einer von uns (oder sogar wir selbst). Ausserdem liegt der Spass beim Bugfixing im Tüfteln und Analysieren, ganz in Sherlock Manier eben. Der schönste Moment ist, wenn man die Ursache gefunden und (fast wichtiger!) auch verstanden hat. Der Weg dahin ist oftmals qualvoll und überhaupt nicht spassig. Noch schöner ist es, wenn man durch das eigene logische Denken auf die Lösung gekommen ist.
Natürlich gibt es noch weitere, feinere Verfahren. Aber mit diesen zwei komme ich meist einen guten Schritt weiter. Gerade wenn viele Unbekannte im Spiel sind.
In seltenen Fällen kommt es vor, dass Bugs sich von selber lösen, sprich einfach nicht mehr auftreten. Für uns sicher der frustrierendste Fall, weil wir die Lösung nie erfahren! Wenn Bugs plötzlich und ohne ersichtliche Veränderung des Systems auftreten, spricht man auch von Gremlins. Wenn Bugs sich plötzlich in Luft auflösen, spreche ich gerne von Heinzelmännchen.
Aktuell habe ich eine aussergewöhnlich harte Knacknuss gefasst. Es sieht so aus, als wären Tatwaffe und Tatort bekannt. Nach Rücksprache mit dem User kann ich den Fehlerfall sogar regelmässig (aber nicht jedes Mal und nicht in jeder Umgebung!) nachstellen, dennoch werde ich das Gefühl nicht los, dass der Tatort ein ganz anderer ist.
Beim Debugging den Fehler nachzustellen, klappt selten, aber ich habe es geschafft. Leider kommt eine Messagebox, dh. der Fehler ist abgefangen und ich sehe nirgends eine Exception oder einen Hinweis im Log. Die Codeanalyse hat mir ebenfalls keine Erkenntnisse gebracht. Ich fürchte jedoch, dass Ursache und Wirkung weit auseinander liegen. Also gehe ich weit, weit zurück und suche erst mal nach der Meldung der Messagebox im Code (ist vermutlich übersetzt, aber hey, ich könnte ja Glück haben!) und dann eben in Google. Da die Meldung jedoch sehr allgemein gehalten ist (Session Timeout) habe ich wenig Hoffnung. Einige Hinweise finde ich in den Foren des Herstellers. Vielleicht ist da etwas dabei. Ich bleibe dran.
Was war euer härtester Fall? Was ist eure häufigste und erfolgreichste Methode? Schreibt sie mir gern als Kommentar auf diesen Eintrag.
In diesem Sinne wünsche ich all den Sherlocks der IT da draussen happy Bugfixing und merry Christmas!
