Dieser Artikel ist eine überarbeitete Version einer Nachricht, die ich kürzlich im Multics-Forum auf LinkedIn veröffentlicht habe.
Es kann ein starker Anreiz sein, wenn Ihre Änderungen sehr schnell "live" gehen. Dies ist die Geschichte des ersten Fehlers, den ich in Multics einbrachte. Multics war ein großes Betriebssystem, das in den späten 1960er und frühen 1970er Jahren am MIT entwickelt wurde.
Ich war ein junger MIT-Student, der in das Multics-Projekt aufgenommen worden war. Ich meldete mich freiwillig, um dem Befehl dprint ("daemon print") eine Funktion hinzuzufügen, mit der Anfragen für den Zeilendrucker-Daemon in eine Warteschlange gestellt wurden. Einer der Manager bat mich, die Anzahl der Kopien in der Anforderung aufzuzeichnen, anstatt N Anforderungen in die Warteschlange aufzunehmen. Diese Änderung würde eine Wettlaufsituation lösen, bei der abgeschlossene Druckaufträge gelöscht werden. 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. Die Freude war jedoch nur von kurzer Dauer, denn schon bald ging ich an mein Bürotelefon und hörte einen wütenden Benutzer, der sich beschwerte, dass ich sein Programm kaputt gemacht hatte. Ich ging zurück und stellte fest, dass ich den Einstiegspunkt des Unterprogramms in dieselbe Quelldatei weder bemerkt noch getestet hatte. Und tatsächlich, ich hatte es kaputt gemacht. Ich reparierte ihn und das Leben ging weiter. Aber ich habe diesen Telefonanruf nie vergessen. Ich bin immer noch nicht perfekt, aber diese wütende Stimme, die in meinem Kopf widerhallte, hat mich im Laufe der Jahre vor vielen ähnlichen, unbedachten Fehlern bewahrt.
Der Aphorismus, den ich in diesem Fall geprägt habe, lautet "Ungetesteter Code funktioniert nicht".
Testen Sie Ihren Code. Finden Sie Ihre eigenen Fehler; zwingen Sie nicht andere, sie zu finden. Vermeiden Sie die wütende Stimme!
Unternehmen