The Repeat Offenders: Characterizing and Predicting Extremely Bug-Prone Source Methods
Die Studie untersucht extrem fehleranfällige Methoden in Java-Projekten, stellt fest, dass diese zwar nur einen kleinen Anteil der gesamten Methoden ausmachen, aber einen unverhältnismäßig großen Teil der Bugs verursachen, und zeigt, dass sie sich trotz statistischer Unterschiede schwer vorhersagen lassen, aber durch wiederkehrende Merkmale identifiziert werden können.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Das Problem: Nicht alle Fehler sind gleich schlimm
Stellen Sie sich einen riesigen, komplexen Baukasten vor (ein Softwareprojekt). In diesem Baukasten gibt es Millionen von kleinen Bauteilen (den sogenannten „Methoden" im Code).
Bisher haben Forscher und Entwickler versucht, herauszufinden, welche dieser Bauteile kaputtgehen könnten. Aber sie haben dabei einen Fehler gemacht: Sie haben alle Bauteile, die einmal kaputtgegangen sind, als gleich gefährlich eingestuft.
Die neue Erkenntnis dieser Studie: Es gibt eine ganz spezielle Gruppe von Bauteilen, die wir „Wiederholungstäter" nennen könnten.
- Ein normales Bauteil geht vielleicht einmal kaputt, wird repariert und funktioniert dann gut.
- Ein Wiederholungstäter ist wie ein Bauteil, das ständig ausfällt. Man repariert es, es geht wieder kaputt, man repariert es erneut, und es fällt wieder aus.
Diese wenigen „Wiederholungstäter" sind die wahren Übeltäter. Sie machen zwar nur einen winzigen Teil aller Bauteile aus (weniger als 1 %), aber sie verursachen über 75 % aller Probleme in einem Projekt. Wenn man diese wenigen „schlechten Apple" ausfindig macht und repariert, spart man eine Menge Zeit und Nerven.
Was haben die Forscher gemacht?
Die Forscher von der University of Manitoba haben sich die Geschichte von 1,25 Millionen Bauteilen aus 98 verschiedenen Open-Source-Projekten (wie große Baustellen) angesehen. Sie wollten drei Dinge herausfinden:
Wie oft kommen diese Wiederholungstäter vor?
- Ergebnis: Sie sind sehr selten. Aber wenn sie da sind, verursachen sie einen riesigen Chaos-Stau.
Sieht man ihnen an, dass sie problematisch sind, bevor sie überhaupt eingebaut werden?
- Ergebnis: Ja und Nein. Wenn man sich das neue Bauteil genau ansieht, sieht man sofort, dass es „krass" ist: Es ist riesig, schwer zu lesen, verwirrend aufgebaut und wirkt instabil. Es ist wie ein Haus, das auf einem wackeligen Fundament gebaut wurde und zu viele Fenster hat.
- Aber: Selbst wenn man diese Warnsignale sieht, ist es für Computer (Künstliche Intelligenz) extrem schwer, vorherzusagen, dass dieses Bauteil in Zukunft zum Wiederholungstäter wird. Die Computermodelle waren hier ziemlich ungenau.
Was haben diese Wiederholungstäter gemeinsam?
- Da die Computer nicht gut genug waren, haben die Forscher die 287 schlimmsten Fälle von Hand untersucht. Sie haben wie Detektive nach Mustern gesucht.
Was haben sie bei den „Wiederholungstätern" gefunden?
Die Forscher haben drei Kategorien von Merkmalen entdeckt, die diese problematischen Bauteile auszeichnen:
1. Das Aussehen (Visuelle Merkmale):
Stellen Sie sich vor, Sie schauen in einen Code wie in einen Text. Bei diesen Wiederholungstätern ist der Text oft:
- Zu lang: Ein einziger Befehl, der so lang ist wie ein ganzer Roman.
- Unleserlich: Wie ein Text, der ohne Absätze und mit wilden Einrückungen geschrieben wurde.
- Verwirrend: Viele „Wenn-dann"-Entscheidungen, die sich ineinander verschachteln wie eine Matroschka-Puppe.
- Mit „Sorgen-Zetteln": Entwickler haben Kommentare hinterlassen wie „TODO: Das hier muss noch gemacht werden" (technische Schulden), aber es wurde nie erledigt.
2. Die Aufgabe (Kontext):
Was machen diese Bauteile eigentlich?
- Oft sind sie das Herzstück des Programms. Sie steuern die wichtigste Logik (z. B. wie ein Spiel funktioniert oder wie Daten verarbeitet werden).
- Sie verarbeiten Daten oder kommunizieren mit der Außenwelt (z. B. Datenbanken).
- Weil sie so wichtig sind, werden sie ständig geändert, und bei jeder Änderung schleichen sich neue Fehler ein.
3. Die Fehlerursache (Warum sie kaputtgehen):
- Falsche Logik: Die Bedingungen sind falsch gesetzt (z. B. „Wenn es regnet, nimm den Schirm" – aber der Code sagt „Wenn es regnet, lass den Schirm zu Hause").
- Schlechte Fehlerbehandlung: Wenn etwas schiefgeht, weiß das Programm nicht, wie es reagieren soll, und stürzt ab.
- Vergessene Randfälle: Es wurde nicht bedacht, was passiert, wenn der Nutzer eine leere Eingabe macht oder eine Zahl negativ ist.
Die große Lektion für die Praxis
Warum ist das wichtig?
- Für Entwickler: Wenn Sie einen riesigen, unleserlichen Code sehen, der die Kernlogik steuert und voller „TODO"-Kommentare ist – passen Sie auf! Das ist wahrscheinlich ein zukünftiger Wiederholungstäter. Bringen Sie ihn in Ordnung, bevor er zu viel Schaden anrichtet.
- Für die Forschung: Computermodelle allein reichen noch nicht aus, um diese Probleme vorherzusagen. Wir brauchen bessere Werkzeuge, die nicht nur auf die Größe des Codes schauen, sondern auch verstehen, was der Code tut und wie er sich im Laufe der Zeit verändert.
Zusammenfassend:
Die Studie sagt uns: „Suchen Sie nicht nach allen Fehlern im System. Suchen Sie nach den wenigen, lauten, chaotischen Wiederholungstätern. Sie sind selten, aber sie verursachen den meisten Ärger. Wenn Sie diese in den Griff bekommen, wird Ihr Software-Projekt viel stabiler."
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.