Diese Geschichte ist eine überarbeitete Version einer Nachricht, die ich kürzlich im Multics-Forum auf LinkedIn gepostet habe.
Wenn deine Änderungen schnell umgesetzt werden, kann das ein starker Anreiz sein. Das ist die Geschichte über den ersten Bug, den ich in Multics eingebaut habe, ein wichtiges 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 Anfragen für den Zeilendrucker-Daemon in eine Warteschlange stellte. Einer der Manager bat mich, die Anzahl der Kopien in der Anfrage zu erfassen, anstatt N Anfragen zur Warteschlange hinzuzufügen. Diese Änderung würde ein Race Condition-Problem lösen, das mit dem Löschen abgeschlossener Druckaufträge zusammenhing. Ich nahm die Änderungen vor und testete sie zu meiner Zufriedenheit.
Meine Änderungen wurden schnell installiert und ich war total begeistert, dass ich das System verbessern durfte. Aber meine Begeisterung hielt nicht lange an, denn kurz darauf ging ich ans Telefon in meinem Büro und hörte mir die Beschwerde eines wütenden Nutzers an, dass ich sein Programm kaputt gemacht hätte. Ich ging zurück und sah, dass ich den Einstiegspunkt der Subroutine in derselben Quelldatei nicht bemerkt oder getestet hatte. Tatsächlich hatte ich ihn kaputt gemacht. Ich habe das Problem behoben und das Leben ging weiter. Aber ich habe diesen Anruf 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 Aphorismus, den ich aus diesem Fall abgeleitet habe, lautet: „Ungetesteter Code funktioniert nicht.“
Testen Sie Ihren Code. Finden Sie Ihre eigenen Fehler, damit andere sie nicht finden müssen. Vermeiden Sie wütende Stimmen!