Viele Softwareentwicklerinnen und -entwickler lernen Data Science, um die Daten ihrer Kundschaft zu analysieren. Immer mehr merken dabei: Mit denselben Methoden lassen sich auch eigene Fragen beantworten, zum Beispiel:
- Wann ist dieses Projekt versandbereit?
- Welche Komponenten unserer Anwendung brauchen am dringendsten Tests?
- Wer sollte diesen Bug beheben?
- Welche Teile meiner API bereiten Nutzerinnen und Nutzern die größten Schwierigkeiten?
In den vergangenen 15 Jahren ist die empirische Forschung im Software Engineering regelrecht explodiert, nicht zuletzt dank Datenquellen wie GitHub und Stack Overflow. Dieser Beitrag stellt einige prägnante Ergebnisse vor und beleuchtet die Methoden hinter drei davon etwas genauer.
Wenn du mehr darüber erfahren möchtest, wie du mit Data Science ähnliche Einblicke in deine eigenen Projekte gewinnst, sag mir gern Bescheid.
Data Science und Software Engineering: Beispiele
Beginnen wir mit einem Befund, der alle betrifft, die Data Science im großen Maßstab betreiben: Yuan et al. haben herausgefunden, dass einfache Tests die meisten kritischen Ausfälle in verteilten, datenintensiven Systemen verhindern können. Sie untersuchten Ausfälle in Cassandra, Hadoop MapReduce und ähnlichen Systemen und stellten fest:
- Fast alle Ausfälle ließen sich mit drei oder weniger Rechenknoten reproduzieren. Mit anderen Worten: Zum Debuggen eines Clusters braucht man meist keinen Cluster.
- Fehlerprotokolle enthielten in der Regel genug Informationen, um die Reproduktion zu ermöglichen.
- Die Mehrheit katastrophaler Ausfälle hätte sich durch einfache Tests des Fehlerbehandlungscodes leicht verhindern lassen.
Der letzte Punkt ist der überraschendste. Profis prüfen zwar üblicherweise, ob ihr Analysecode funktioniert, wenn alles glattläuft, testen aber selten, ob er im Fehlerfall richtig reagiert. Schon wenige zusätzliche Tests während der Entwicklung würden später viel Ärger vermeiden.
Ein weiteres Großstudien-Ergebnis stammt aus der Arbeit von Altadmri und Brown, die 37 Millionen Kompilier-Versuche von britischen Oberstufenschülerinnen und -schülern analysierten. Anschließend fragten sie Lehrkräfte nach den häufigsten Fehlern ihrer Klassen und entdeckten:
- Lehrkräfte waren sich uneinig, welche Fehler am wahrscheinlichsten auftreten.
- Noch wichtiger: Ihre Vorhersagen korrelierten nur schwach mit den tatsächlichen Fehlern der Lernenden.
Natürlich ist Data Mining nicht der einzige Weg zu belastbaren, evidenzbasierten Einsichten in der Programmierung. 2013 veröffentlichte das Team von Andreas Stefik die zweite Studie einer Reihe zur Frage, ob manche Sprachen sich leichter erlernen lassen als andere. Als Basislinie nahmen sie eine ausgedachte Sprache mit zufällig generierten Schlüsselwörtern auf.
Zu ihrer Überraschung waren geschweifte-Klammern-Sprachen wie Java und Perl für Anfängerinnen und Anfänger genauso schwer zu erkennen wie die Zufallssprache. Python und Ruby ließen sich deutlich leichter lernen, und Quorum, das die Syntax jeder neuen Funktion per A/B-Test evaluiert, war noch zugänglicher. Andreas bespricht dieses Ergebnis – und warum Sprachdesignerinnen und -designer der Nutzbarkeit so wenig Beachtung schenken – in diesem unterhaltsamen Podcast.
Security-Bugreports erkennen
Als Beispiel für die Vorgehensweise in solchen Studien nutzte Fayola Peters am LERO textbasierte Vorhersagemodelle, um Meldungen zu Sicherheitslücken in den Bugtrackern großer Systeme zu identifizieren und so deren Bearbeitung zu priorisieren. In einer Studie verwendete sie Daten aus den Projekten Chromium, Wicket, Ambari, Camel und Derby; insgesamt 45.940 Bugreports, von denen nur 0,8 % Sicherheitslücken betrafen.
Einige Sicherheitsbugs sind manuell gekennzeichnet und lassen sich zum Trainieren von Klassifikatoren nutzen, um unmarkierte Fälle zu erkennen. Techniken wie Naïve Bayes und Random Forests sind ein guter Startpunkt, doch die Effizienz generischer Modelle lässt sich oft durch das Filtern spezifischer Schlüsselwörter steigern. Der wichtigste Test ist, wie gut Modelle aus Projekten mit gelabelten Sicherheitsbugs ähnliche Bugs in anderen Projekten finden. Die Ergebnisse waren ermutigend: Peters stellte fest, dass ihre Klassifikatoren in der Praxis ausreichend gut funktionieren.
Wird mein Patch akzeptiert?
Als zweites Beispiel: Unternehmen möchten ihre Änderungen in Projekte einbringen, um sich eigene Wartung zu ersparen, und Freiwillige wollen wissen, ob ihr Patch eine Chance hat. Da zwischen Einreichung und Annahme oft viel Zeit vergeht, entwickeln Bram Adams und sein Team an der Polytechnique Montréal Modelle zur Vorhersage, welche Patches akzeptiert werden.
Wie viele Data-Science-Projekte beginnt auch dieses mit dem Abruf und der Bereinigung von Daten aus mehreren Quellen, darunter Git-Repositories und Gerrit-Code-Reviews. Für Projekte mit E-Mail-basiertem Review wie den Linux-Kernel bedeutet Datensammlung jedoch das Scrapen von Mailinglisten-Archiven und Heuristiken wie Prüfsummen von Patches oder Mengen-Schnittmengen geänderter Zeilen, um Patches Konversationen zuzuordnen. Selbst mit Tools wie GrimoireLab bleiben Fälle, in denen mehrere Versionen eines Patches begutachtet wurden, oder ein Patch in mehrere, separat geprüfte Teile aufgespalten ist. Wie in jeder Data Science liegt es an der Analystin oder dem Analysten, ein Modell zu bauen – und dessen Annahmen prägen die Ergebnisse maßgeblich.
Im zweiten Schritt geht es darum, Variablen und passende Metriken festzulegen, zum Beispiel:
- Patch-Qualität
- Erfahrung der Patch-Autorin bzw. des Patch-Autors
- Review-Prozess (etwa Review-Kommentare und Zahl der Reviewer)
- Review-Qualität (zum Beispiel Detailtiefe der Reviews)
- Review-Dauer
- Interaktion zwischen Patch-Autor und Reviewern (zum Beispiel freundlich vs. verärgert)
Schon dieses halbe Dutzend kann alles von Überlebenszeitanalysen bis Stimmungsanalyse erfordern. Steht fest, was gemessen wird, kommen die Data-Science-Werkzeuge zum Einsatz, die DataCamp-Kurse vermitteln. Da das eigentliche Ziel die Vorhersage künftiger Patch-Annahmen ist, bietet sich logistische Regression an – neben vielen Alternativen.
Abschließend lässt sich die Variablenbedeutung messen, um den Einfluss jeder Variable auf die Patch-Annahme zu bestimmen. Das ist zwangsläufig teilweise qualitativ, denn das Ziel ist, konkrete Hebel zu identifizieren, mit denen Entwicklerinnen und Entwickler die Chancen erhöhen, dass ihre Arbeit ins Produkt gelangt. Wie immer gilt: Korrelation ist nicht Kausalität. Aber schon wenige einfache Empfehlungen (wie "VERWENDE IN COMMIT-MESSAGES KEINE DAUER-GROSSSCHREIBUNG") können spürbar helfen.
Hilfe finden
Die größte Veränderung in der Arbeit von Programmierenden in den letzten 20 Jahren betrifft nicht die Sprachen, sondern die fast universelle Nutzung von Stack Overflow für Fragen und Antworten. Christoph Treude von der University of Adelaide und seine Mitforschenden entwickeln Methoden, um solche Plattformen noch hilfreicher zu machen.
Ausgangspunkt ist der Stack-Overflow-Dump. Nach explorativen Analysen wie Wort- und Satzlängen, häufigsten Wörtern, Termfrequenz–Inverse-Dokumentfrequenz (TF-IDF) und mehr folgt der nächste Schritt: zu untersuchen, welche Wörter in Threads mit höheren Bewertungen, höheren Annahmeraten und mehr Views gemeinsam auftreten.
Da Softwaredokumentation viele unvollständige Sätze und Code-Elemente enthält, liegen Standardbibliotheken für natürliche Sprachverarbeitung oft daneben. Noch schwieriger wird es bei Dokumentation in anderen Sprachen als Englisch, da technische Terminologie häufig weiterhin auf Englisch verwendet wird – es mischen sich also zwei natürliche Sprachen mit Code. Um solche Fälle zu bewältigen, braucht es Ad-hoc-Heuristiken in Kombination mit fortgeschritteneren Modellierungstechniken.
Aus all dem lässt sich ein Tool bauen, das den Namen eines Python-Moduls entgegennimmt und aus Stack-Overflow-Threads sinnvolle Sätze zu diesem Modul erzeugt. Einen Schritt weiter nutzten Treude und Kolleginnen/Kollegen grammatikalische Abhängigkeiten zwischen Wörtern, um automatisch Softwaredokumentation zu finden, die erklärt, wie man eine Aufgabe löst, und anschließend Code-Snippets zu identifizieren, die diese Aufgabe umsetzen.
Fazit
Allzu oft stützen sich vermeintliche Wahrheiten über Softwareentwicklung eher auf starke Meinungen und laute Stimmen als auf Belege. Wie eingangs beschrieben, ändert sich das: Jedes Jahr erscheinen Hunderte hochwertiger Studien, die manche Überzeugungen stützen – etwa "Code-Reviews sind wirklich der beste Weg, Bugs zu finden" – und andere infrage stellen, zum Beispiel "Testgetriebene Entwicklung ist weniger wirksam, als manche glauben, und goto-Anweisungen sind nicht per se schädlich".
"Ingenieurwesen" wurde als "Anwendung der wissenschaftlichen Methode zur Schaffung nützlicher Dinge" definiert. Wenn das stimmt, ist die Softwareentwicklung dank Data Science endlich auf dem Weg, eine echte Ingenieurdisziplin zu werden. Wenn du dir Kurse wünschst, die zeigen, wie du Data Science in der Softwareentwicklung anwendest, gib uns bitte Bescheid.
Weiterführende Literatur
Jedes Jahr präsentieren Forschende auf Konferenzen wie Mining Software Repositories Dutzende neuer Ergebnisse in diesem Bereich. Einige Proceedings sind noch hinter Paywalls versteckt, aber immer mehr Forschende stellen Preprints frei zur Verfügung.
Für einen Überblick empfiehlt sich der Sammelband von 2010: Making Software – eine Art "Best of" der spannendsten Befunde jener Zeit. Eine neue Trilogie mit den Titeln Perspectives on Data Science for Software Engineering, The Art and Science of Analyzing Software Data und Sharing Data and Models in Software Engineering deckt dieselben Themen breiter und aktueller ab. Separat dazu arbeitet Derek Jones an einem neuen Buch mit dem Titel Empirical Software Engineering Using R.