Preisgekrönte Fehlersuche: Gestern lief es doch noch!
Andreas Zeller ist nicht nur der Schöpfer des GNU DDD Debuggers, sondern auch der Vater des so genannten Delta-Debuggings. Als Professor lehrt Zeller an der Universität des Saarlandes und seine Forschung zielt vor allem darauf ab, wie sich die Produktivität eines Entwicklers steigern lässt. Für das Delta-Debugging hat Zeller jetzt den in Software-Kreisen renommierten ‘Impact Award’ gewonnen. silicon.de feiert das mit einem Interview.
silicon.de: Haben sie eine Datenbank, in der sämtliche Zustände gespeichert werden? Wie darf man sich das Verfahren vorstellen.
Zeller: Wir haben eine Geschichte der Änderungen, eine so genannte Versionsgeschichte. Das gehört sozusagen zum Handwerkszeug der systematischen Software-Entwicklung, dass man stets weiß, wer was wann getan hat.
silicon.de: Dafür gibt es ja Versionierungs-Tools.
Zeller: Ja, die bekanntesten heißen CVS oder Subversion. Und dann hab ich mir überlegt, wenn man eine Version hat, die vor einem Monat noch funktioniert hat und dann ein paar Tausend Änderungen später, etwa nach einem Monat die Software nicht mehr arbeitet, dass man durch systematisches Suchen, die Fehlerverursachung finden könnte.
Im einfachsten Fall kann man sich das so vorstellen, dass man den Zeitraum nimmt und den immer halbiert und dann prüft, ob der Fehler in der Mitte passiert ist. Also vereinfacht gesagt. Wenn etwas vor einem Monat noch lief, und heute nicht, dann schau ich mir an, was vor 14 Tagen war. Wenn der Fehler hier nicht zu finden ist, dann prüfe ich, was vor einer Woche war und so kann man das immer weiter eingrenzen.
silicon.de: Also es wird nicht alleine der Code geprüft, sondern dem ganzen wohnt auch eine zeitliche Komponenten inne.
Zeller: Das Kuriose daran ist, dass ich zunächst überhaupt nicht auf den Code schau, sondern alleine auf das Wissen, dass es eine Konfiguration gibt, in der es funktioniert, eine andere, in der es nicht mehr funktioniert. Wir suchen den minimalen Unterschied mit dem minimalsten Zeitabstand. Wir können dann am Ende sagen, als diese Zeile von A nach B geändert wurde, wurde der Fehler verursacht. Das ist für den Programmierer außerordentlich praktisch, da er zum einen sehr schnell den Fehler finden und auch beheben kann. Somit kann er dann schnell die Änderung zurücknehmen und dann weiß man, dass zumindest dieser Fehler nicht mehr auftritt. Aber es kann natürlich passieren, dass dadurch andere Fehler eingefügt werden, deshalb kann man das nicht ganz automatisieren. Aber als erste Handhabe für den Programmierer, der eine vollautomatische Diagnose bekommt, ist das sehr praktisch und hilfreich.
