Wil Shipley gibt in seinem abonnierenswerten Blog einen Blick auf das Debugging von Delicious Library. Ein sehr interessanter Artikel – auch wenn ich nach dessen Lektüre gemerkt habe, dass auch die nur mit Wasser kochen. Da sie aber keine Web-Applikation entwickeln, die auf einem bestimmten Server mit bestimmter Software läuft, ist die Fehlersuche deutlich aufwendiger. Nicht so aufwendig wie bei Microsoft Windows, dass noch einmal eine Million weiterer Kombinationen von Hard- und Software vorweist als die relative bescheidene Mac OS X-Plattform.
Einige Ausschnitte, die mir persönlich gefallen haben:
Now, let me state something unequivocally: 98% of the time when you think you’ve found a bug that is not your fault, it really is your fault. The other 2% of the time… well, it’s probably your fault as well.
Quelle (im folgenden): Pimp My Code, Part 8: Mary, Mary, why you buggin?
Das ist nicht nur beim Programmieren so, sondern auch beim PC-Support. Allzuoft schiebt man dem Benutzer die Schuld in die Schuhe und muss im nachhinein zugeben, dass er überhaupt nicht für den Fehler verantwortlich ist.
Oder man erinnere sich daran, was/wem man die Schuld in die Schuhe schob, als man das letzte Mal etwas verloren hatte und es nicht mehr finden konnte. Zuerst verdächtigt man jedes einzelne Mitglied der Familie als den hinterhältigen Bösewicht, bis man am Schluss eingestehen muss, dass man den Schlüsselbund wohl selber unters Sofa fallen liess.
Es entspricht wohl einfach dem menschlichen Ego, aus Reflex zuerst einmal die Mitmenschen für Fehler und eigenes Fehlverhalten verantwortlich zu machen.
First off, when you’re tracing down a bug, keep your mind open. Don’t get married to a theory or an approach. This isn’t like programming, you’ve got to defocus your mind, read a bunch, look at your code. Don’t think „I know I did this,“ think, „I *thought* I did this, but maybe I’m crazy.“ Question EVERY LINE around the crash. Does „if“ really mean what I think it does? Does „*“ bind tighter than „++“? Did I really write the correct variable name there, or did I write in some different variable and I keep reading it as the correct variable because that’s what I meant to write?
Das ist ein weiteres Problem beim Debugging: Es ist sehr schwer, den im Geiste bildlich vorhandenen Code (der natürlich funktioniert, ist ja klar! *smile*) beiseite zu schieben und die tatsächlich niedergeschriebenen Anweisungen zu realisieren. Es erfordert grosse Konzentration, zu erkennen, was man schlussendlich wirklich zu „Papier“ gebracht hat. Gelingt dies, findet man den Fehler wenige Minuten später.
Debuggen will gelernt sein!
A propos debuggen: Ich kann mich gut daran erinnern, als ich im 2001 für einige Monate bei einem Gymer-Kollegen in seinem Studenten-Studio in Zürich unterkam (er war … im Militär?). Es war ein Studentenwohnheim an der Wehntalerstrasse, wenn ich mich richtig erinnere, wo sich weitere Kollegen aus dem Kirchenfeld aufhielten und ihr erstes Semester Elektro-Technik an der ETH absolvierten.
Der Zufall wollte es, dass ich eines Abends bei einem Kollegen auf ein Bier vorbeiging und dieser mit den anderen Studenten vor dem Laptop sass und Java-Übungen programmierte.
Fasziniert sah ich ihm über die Schultern, als das Programm Fehlermeldungen ausspuckte. Hilflos sass er vor dem Computer, sah die Fehlermeldungen an – und wusste nicht weiter. Da ich Java bis heute nicht erlernt habe, konnte ich ihm nicht in spezifischen Fragen helfen. Doch mich juckte es förmlich in den Fingern, einzugreifen und das zu tun, was ich täglich bei streikenden .asp und .php-Scripts tat: print()-Befehle einzubauen, um zu schauen, wo genau der Code durchkam und welche Abschnitte er nicht erreichte. Oder auch, welchen Wert eine Variable zugewiesen bekam. Ihm mangelte dieses Wissen und die Erfahrung, weil er noch nie aus eigenem Antrieb etwas programmiert hatte und ihm somit die Übung und die Verbissenheit fehlte. Das Problem liess sich einfach nicht lösen, indem man nur auf den Bildschirm starrte. Man musste etwas tun – den Profi-Coder zu rufen und ihn das Debugging übernehmen zu lassen, war aber wohl die schlechteste Idee von allen …
Damals begann es mir zu dämmern, dass Programmieren die eine, richtiges Debuggen die andere Fähigkeit eines guten Entwicklers ist. Wer das eine gut konnte, war noch nicht prädestiniert, auch das andere – das Auftreten von Fehlern und unerwartetes Verhalten von Programm-Code – richtig zu handhaben.
Moral der Geschicht: Noch während den Prüfungen im Sommer kam besagter Kollege zurück auf Bern und begann im nächsten Semester einen neuen Studiengang.
