Dieser Beitrag ist eine überarbeitete Fassung eines Beitrags, den ich kürzlich im Multics-Forum auf LinkedIn gepostet habe.
Wenn Änderungen sehr schnell „live“ gehen, kann das ein starker Anreiz sein. Dies ist die Geschichte des ersten Fehlers, den ich in Multics verursacht habe – ein bedeutendes Betriebssystem, das Ende der 1960er und Anfang der 1970er Jahre am MIT entwickelt wurde.
Ich war ein junger Studienanfänger am MIT, der in das Multics-Projekt aufgenommen worden war. Ich meldete mich freiwillig, um dem Befehl „dprint“ („Daemon Print“) eine Funktion hinzuzufügen, die Druckaufträge für den Zeilendrucker-Daemon in eine Warteschlange stellte. Einer der Projektleiter bat mich, die Anzahl der Kopien im Auftrag zu erfassen, anstatt N Aufträge in die Warteschlange einzureihen. Diese Änderung würde eine Race Condition beheben, die beim Löschen abgeschlossener Druckaufträge auftrat. Ich nahm die Änderungen vor und testete sie zu meiner Zufriedenheit.
Meine Änderungen wurden bald installiert, und ich war begeistert, dass ich das System verbessern durfte. Doch meine Begeisterung währte nur kurz, denn schon bald ging ich ans Bürotelefon und hörte mir die Beschwerde eines wütenden Benutzers an, der mir vorwarf, ich hätte sein Programm kaputtgemacht. Ich schaute noch einmal nach und stellte fest, dass ich den Einstiegspunkt der Unterroutine in derselben Quelldatei übersehen und nicht getestet hatte. Tatsächlich hatte ich ihn kaputtgemacht. Ich habe den Fehler behoben und das Leben ging weiter. Aber diesen Anruf habe ich nie vergessen. Ich bin immer noch nicht perfekt, aber diese wütende Stimme, die in meinem Kopf nachhallt, hat mich seitdem vor vielen ähnlichen, unachtsamen Fehlern bewahrt.
Der Leitsatz, den ich aus diesem Fall abgeleitet habe, lautet: „Nicht getesteter Code funktioniert nicht.“
Teste deinen Code. Finde deine Fehler selbst; überlasse es nicht anderen, sie zu finden. Vermeide wütende Reaktionen!