Software-Änderungen mit Machine Learning verbessern

Software ist überall! Von Apps bis zu Computerprogrammen, wir sind auf sie für Spass und Arbeit angewiesen. Aber je grösser und komplexer die Software wird, desto schwieriger kann es sein, Änderungen vorzunehmen. Manchmal muss man, wenn man einen Teil ändert, auch einen anderen Teil anpassen, der damit verbunden ist. Das nennt man eine „Co-Change-Beziehung.“ Stell dir vor, die Bremsen und der Motor deines Autos müssten gleichzeitig repariert werden – wenn du dich nur auf eines konzentrierst, wird’s ein Chaos.

Wie finden Entwickler also heraus, welche Teile der Software zusammen geändert werden müssen? Traditionell mussten sie sich auf ihr Gedächtnis, ihre Erfahrung und chaotische Dokumentationen verlassen. Spoiler-Alarm: Das ist nicht die effektivste Methode. Hier kommen wir mit einem smarteren Ansatz ins Spiel.

#Die Herausforderung der Veränderung

Grosse Softwaresysteme können wie eine eng verbundene Gemeinschaft sein. Wenn ein Mitglied geändert wird, müssen andere vielleicht auch angepasst werden. Das gilt besonders für Methoden in der Programmierung – denk an sie als nützliche kleine Funktionen, die bestimmte Aufgaben erledigen. Wenn eine Methode aktualisiert wird, müssen möglicherweise auch andere, die eng damit arbeiten, beachtet werden.

Diese Co-Change-Beziehungen zu erkennen, kann schwierig sein. Frühere Methoden hatten oft viele Fehlalarme – sie haben zu viele nicht verwandte Änderungen gemeldet. Stell dir einen Feueralarm vor, der jedes Mal losgeht, wenn jemand Wasser kocht; das erzeugt ohne Grund Panik.

Um dieses Problem anzugehen, brauchen wir einen besseren Ansatz. Statt nur die spezifischen Änderungen zu betrachten, müssen wir den grösseren Kontext berücksichtigen – der findet sich normalerweise in etwas, das „Pull Requests“ genannt wird, das wie Gruppenänderungen ist, die gemeinsam vorgenommen werden.

#Ein neuer Weg, Co-Changes zu bewerten

Wir haben beschlossen, etwas Intelligenz aus dem Maschinenlernen einzubringen, was so ist, als würden wir Computern beibringen, aus Daten zu lernen. Was wäre, wenn wir ein Modell trainieren könnten, das herausfindet, welche Methoden am wahrscheinlichsten zusammen geändert werden? Das nennt man eine „Learning to Rank“ (LtR) Methode. Es ist wie einem virtuellen Assistenten eine Liste von Aufgaben zu geben und ihn zu bitten, die wichtigsten auszuwählen.

Unsere Idee ist, zu berechnen, wie oft Methoden in der Vergangenheit gemeinsam geändert wurden, und sie danach zu bewerten. Je mehr sie zusammengearbeitet haben, desto höher stehen sie auf der Liste der zu prüfenden Punkte. So wissen Entwickler, wo sie ihre Aufmerksamkeit lenken müssen.

Wir haben Tests an satten 150 Open-Source-Java-Projekten durchgeführt (das ist viel!). Mit über 41 Millionen Codezeilen hatten wir definitiv viel zu tun. Aber wir haben herausgefunden, dass unsere Methode ziemlich gut funktioniert, insbesondere mit dem Random Forest-Modell. Denk daran wie an ein superintelligentes Abstimmungssystem, bei dem viele kleine Entscheidungen zu einer soliden Antwort führen.

#Was testen wir eigentlich?

Wenn wir tiefer in unsere Tests eintauchen, sind wir wirklich neugierig auf ein paar Schlüsselfragen:

1. Wie gut bewertet unser Modell Co-Changed-Methoden? Wir wollen sehen, ob es gut darin ist, vorherzusagen, welche Methoden wahrscheinlich zusammen geändert werden.

2. Kann unsere Methode traditionelle Bewertungsansätze übertreffen? Wir wollen nicht nur besser sein; wir wollen ein Game Changer sein.

3. Welche Merkmale sind am wichtigsten, um präzise Vorhersagen zu treffen? Einige Merkmale könnten wichtiger sein als andere, und das zu wissen, kann helfen, den Prozess zu optimieren.

4. Wie lange bleibt unser Modell genau? Wenn es zu schnell veraltet, müssen wir es ständig aktualisieren – und das kann nervig sein.

#Testzeit!

Um unsere Methode zu bewerten, haben wir verschiedene Experimente erstellt. Zuerst haben wir einen „Goldenen Datensatz“ aus den vergangenen Änderungen zwischen verschiedenen Methoden erstellt. Dieser Datensatz wurde in Trainings- und Testteile aufgeteilt. Der Trainingsteil hilft dem Modell zu lernen, und der Testteil hilft uns zu überprüfen, wie gut das Modell gelernt hat.

Nachdem das Training abgeschlossen war, haben wir unser Modell ausgeführt und seine Leistung mit einem Mass namens NDCG gemessen, was eine schicke Art ist, zu überprüfen, wie gut die Bewertung mit der tatsächlichen Relevanz übereinstimmt.

Unsere Tests zeigten, dass das Random Forest-Modell grossartig darin war, herauszufinden, welche Methoden gemeinsam Aufmerksamkeit benötigten, und sehr hohe Platzierungen im Vergleich zu anderen Modellen erzielte. Es war wie herauszufinden, dass dein Lieblingsrestaurant eine geheime Speisekarte hat – du weisst einfach, dass es gut sein wird.

#Die wichtigen Merkmale

In der Welt der Vorhersagen sind nicht alle Merkmale gleich. Einige sind Superstars; andere hängen nur mit. Unser wichtigstes Merkmal? Die Anzahl der Male, die Methoden in der Vergangenheit gemeinsam geändert wurden! Dieser kleine Faktor hat einen riesigen Einfluss auf unsere Bewertungen. Weitere wichtige Merkmale sind:

• Ähnlichkeit der Pfade: Wie eng die Standorte der Methoden im Projekt miteinander verbunden sind.
• Ähnlichkeit der Autoren: Wenn dieselben Leute an beiden Methoden arbeiten, gibt es eine höhere Chance, dass sie zusammen geändert werden.

Im Gegenzug hatten einige Merkmale überhaupt keinen Einfluss. Zum Beispiel half es nicht, Vorhersagen über Co-Changes zu treffen, wenn die Methoden in Bezug auf den Code ähnlich waren. Es ist wie anzunehmen, dass zwei Cousins beste Freunde sind, nur weil sie Urgrosseltern teilen – nicht immer genau!

#Timing ist alles

Ein weiterer interessanter Faktor, den wir betrachtet haben, war, wie lange wir die vergangenen Daten zum Training nutzen sollten. Zu kurz, und das Modell lernt vielleicht nicht genug; zu lang, und es könnte veraltet sein. Nach dem Test mehrerer Zeitrahmen haben wir herausgefunden, dass die Verwendung von 90 bis 180 Tagen Historie am besten funktioniert. Aber nach 60 Tagen neuer Vorhersagen ist es klug, das Modell neu zu trainieren. Andernfalls riskierst du, dass es dich auf eine Schnitzeljagd schickt.

#Was bedeutet das für Entwickler?

Was bedeutet das also für all die, die in ihren Kellern, Büros oder Cafés programmieren? Hier ist die Scoop:

1. Weniger Bugs: Zu wissen, welche Methoden oft gemeinsam geändert werden, hilft Entwicklern, diese lästigen Bugs zu vermeiden, die auftreten können, wenn Änderungen unbemerkt bleiben.

2. Bessere Codequalität: Wenn Entwickler eng verbundene Methoden erkennen, können sie daran arbeiten, diese weniger voneinander abhängig zu machen, was zu saubererem Code führt. Es ist wie das Entrümpeln eines chaotischen Zimmers; alles wird einfacher zu finden!

3. Verbesserte Zusammenarbeit: Indem Teams die Co-Change-Beziehungen verstehen, können sie verwandte Aufgaben denselben Entwicklern zuweisen, was zu effizienterem Arbeiten führt. Stell dir zwei Köche in einer Küche vor, die zusammenarbeiten – sie geben sich Zutaten und Ideen weiter, was zu einem besseren Gericht führt.

4. Intelligentere Tests: Tester können sich auf Methoden konzentrieren, die wahrscheinlich von Änderungen betroffen sind, und sicherstellen, dass ihre Testanstrengungen den Punkt treffen. Es ist wie eine Karte zu benutzen, statt blind umherzuirren.

#Fazit

In der Welt der Software, wo sich alles ständig ändert und entwickelt, ist es ein Game Changer, eine smarte Möglichkeit zu haben, diese Änderungen zu verfolgen und zu verwalten. Mit maschinellem Lernen, um Co-Changed-Methoden zu identifizieren und zu bewerten, haben wir ein Tool geschaffen, das Entwicklern hilft, ihre Arbeit besser und schneller zu erledigen.

Während wir weiterhin unseren Ansatz verfeinern, könnten wir sogar auf andere Programmiersprachen und Werkzeuge ausweichen, um sicherzustellen, dass diese Lösung noch mehr Entwicklern in der Zukunft zugutekommen kann. Schliesslich, wer liebt nicht ein gutes Upgrade?