From Generic to Personalized: Exploring Persona-Aware Code Review Explanations
Diese Arbeit untersucht das Potenzial personalisierter Erklärungen bei Code-Reviews, indem sie erste Erkenntnisse aus einer Mixed-Methods-Anwenderstudie präsentiert, die aufzeigt, dass die Vorlieben von Entwicklern für Feedback-Stile je nach deren Problemlösungsansätzen, Erfahrung und Rollen variieren, und plädiert letztlich für menschenzentrierte KI-Systeme, die Review-Kommentare an individuelle Bedürfnisse anpassen.
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
Stellen Sie sich vor, Sie sind ein Chefkoch, der versucht, einer Gruppe neuer Köche beizubringen, wie man ein misslungenes Rezept repariert. Sie haben zwei sehr unterschiedliche Arten von Studenten in Ihrer Küche. Ein Student, nennen wir ihn „Tim“, ist ein selbstbewusster, abenteuerlustiger Entdecker, der es liebt, direkt ins Feuer zu springen, mit neuen Gewürzen zu experimentieren und durch Tun herauszufinden, wie es funktioniert. Der andere Student, „Abi“, ist eine vorsichtige, prozessorientierte Planerin, die sich sicherer fühlt, wenn man ihr eine Schritt-für-Schritt-Karte reicht, genau erklärt, warum ein Schritt wichtig ist, und sie davor warnt, wo der heiße Herd steht, noch bevor sie überhaupt eine Pfanne anfasst.
Seit Jahren ist Code-Review (bei dem Entwickler den Computer-Code des jeweils anderen auf Fehler prüfen) so gewesen, als würde ein Chefkoch allen die gleiche generische Anweisung zurufen: „Reparier das!“ oder „Mach es kürzer!“ Das Papier legt nahe, dass dieser „Einheitsansatz“ so ist, als würde man versuchen, Tim und Abi mit derselben Rezeptkarte zu unterrichten. Dies führt oft zu Verwirrung, Frustration und dazu, dass der Code in einer Endlosschleife aus Hin-und-Her-Argumentationen stecken bleibt, anstatt repariert zu werden.
Die Forscher hinter dieser Studie stellten eine einfache Frage: Was wäre, wenn wir das Feedback magisch umschreiben könnten, um es an den jeweiligen Stil anzupassen? Sie wollten sehen, ob ein „Tim-Stil“-Kommentar (kurz, aktionsorientiert, fördert die Unabhängigkeit) besser für Tim funktionieren würde und ob ein „Abi-Stil“-Kommentar (detailliert, risikobewusst, Schritt für Schritt) besser für Abi wäre.
Um dies zu testen, haben sie nicht nur geraten; sie führten ein kleines, praxisnahes Experiment durch. Sie versammelten 16 Entwickler (eine Mischung aus Studenten und Profis sowie eine Mischung aus Leuten, die Code schreiben, und Leuten, die Code prüfen) und zeigten diesen Entwicklern drei verschiedene Code-Stücke und baten sie, zwei Versionen des Feedbacks für jedes Stück zu betrachten: eine, die klang, als sei sie für einen „Tim“ geschrieben worden, und eine, die für einen „Abi“ gedacht war.
Hier ist, was die Studie nahelegt, was basierend auf ihren Messungen geschah:
- Die „Abi“-Fraktion liebte die Karten: Wenn die Entwickler, die sich mit dem „Abi“-Stil identifizierten (insbesondere die weniger Erfahrenen), die detaillierten Schritt-für-Schritt-Erklärungen sahen, die Risiken und Lernmöglichkeiten hervorhoben, fühlten sie sich viel stärker unterstützt. Sie wollten nicht, dass das Feedback kurz und knackig ist; sie wollten das „Warum“ und das „Wie“.
- Die „Tim“-Fraktion war wählerischer: Die „Tim“-Entwickler, die normalerweise selbstbewusster sind, bevorzugten das „Tim-Stil“-Feedback nicht immer so sehr, wie man es erwarten würde. Tatsächlich hatten die weniger erfahrenen „Tim“-Typen manchmal Schwierigkeiten mit den kurzen, rein aktionsorientierten Notizen, da ihnen die Erfahrung fehlte, um die Lücken zu füllen. Die erfahrenen „Tim“-Entwickler schienen jedoch den prägnanten, direkten Stil mehr zu schätzen als den detaillierten.
- Die meisten wollten Tiefe statt Schnelligkeit, aber die Vorlieben variierten: Hier ist ein Schlüsselergebnis der Daten: Während Entwickler im Allgemeinen „Lernunterstützung“, „praktische Vorschläge“ und „Risikobewusstsein“ mehr schätzten als Kürze, war dies keine universelle Regel für jeden. Die „Abi“-Teilnehmer fanden kurze Kommentare stark negativ, aber die „Tim“-Teilnehmer hatten gemischte Ansichten über die Kürze; einige fanden sie akzeptabel oder bevorzugten sie sogar, während andere unsicherer waren. Es scheint, dass in der Welt des Codes Klarheit und Hilfsbereitschaft wichtiger sind als Schnelligkeit, aber das Ausmaß, in dem Kürze geschätzt wird, hängt davon ab, wer man ist.
Das Papier behauptet nicht, ausgeschlossen zu haben, dass eine einzige Art der Erklärung jemals funktionieren könnte, sondern präsentiert vorläufige Ergebnisse und die Vision, dass ein einziger Typ wahrscheinlich nicht perfekt für jeden ist. Die Studie zeigt explizit, dass das, was für den einen offensichtlich erscheint, für den anderen ein verwirrendes Chaos sein kann, je nach Problemlösungsstil, was darauf hindeutet, dass ein „Einheitsansatz“ für diverse Teams wahrscheinlich unzureichend ist.
Was ist also die große Erkenntnis? Die Forscher legen nahe, dass wir an der Schwelle zum Bau eines neuen Typs von „intelligentem Assistenten“ für Code-Reviews stehen. Stellen Sie sich eine KI vor, die nicht nur Ihren Code auf Fehler prüft, sondern auch prüft, wer Sie sind. Wenn Sie ein vorsichtiger Planer sind, gibt sie Ihnen einen detaillierten Leitfaden. Wenn Sie ein kühner Entdecker sind, gibt sie Ihnen einen kleinen Anstoß in die richtige Richtung.
Die Autoren betonen jedoch vorsichtig, dass dies erst der Anfang ist. Sie haben diese Vorlieben in einer kleinen Gruppe von 16 Personen gemessen, und obwohl die Ergebnisse vielversprechend sind, ist es noch kein fertiges Produkt. Sie warnen davor, die Dinge zu vereinfachen oder die Vielfalt der Perspektiven zu verlieren. Das Ziel ist es nicht, das menschliche Urteilsvermögen zu ersetzen, sondern Werkzeuge zu schaffen, die Menschen helfen, einander besser zu verstehen – damit sichergestellt ist, dass sich kein Entwickler zurückgelassen fühlt, weil das Feedback in einer Sprache verfasst wurde, die er nicht spricht.
Kurz gesagt: Die Studie legt nahe, dass die Zukunft des Code-Reviews nicht darin liegt, schneller zu werden, sondern darin, persönlicher, empathischer und ein kleines bisschen mehr wie ein Lehrer zu sein, der genau weiß, wie sein Schüler am besten lernt.
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.