Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Parasoft-Blog
Eine gute Peer-Code-Review-Technik steigert nachweislich die Softwarequalität. Hier sind einige Tipps, um schädliche Praktiken zu verhindern, die Ihre Codeüberprüfungen nutzlos machen könnten.
Zum Abschnitt springen
Die Überprüfung von Code durch Kollegen ist eine jener Praktiken, deren Wert allgemein anerkannt ist, die aber kaum jemand wirklich gut umsetzt. Das liegt nicht an mangelnden guten Absichten – vielmehr an schlechten Angewohnheiten, die sich über Jahre durch kalendergesteuerte Entwicklungszyklen, unklare Richtlinien und die allgemeine menschliche Neigung, unangenehme Gespräche über den Code anderer zu vermeiden, angesammelt haben.
Die gute Nachricht ist, dass die Verbesserung des Peer-Review-Verfahrens hauptsächlich eine Frage der Vermeidung falscher Vorgehensweisen ist.
Automatisierte Tests – Unit-Tests , API-Tests , Performance-Tests , statische Analysen und der Rest – decken die messbaren, wiederholbaren Dinge ab.
Bei der Peer-Review kommt das menschliche Urteilsvermögen zum Einsatz, wo Werkzeuge nicht helfen können: Designprobleme, Wartbarkeit, der leise Alarm, der beim Lesen von Code aufleuchtet und denkt: „Das wird uns später Probleme bereiten.“ Das geschieht nur, wenn Reviews fokussiert, diszipliniert und tatsächlich abgeschlossen werden.
Die Daten zur Effektivität von Peer-Review-Verfahren sind schon so lange bekannt, dass sie ihren eigenen Whisky kaufen könnten. Steve McConnell veröffentlichte diese Zahlen bereits 1993 in Code Complete. Seitdem hat sie niemand substanziell widerlegt, was einiges darüber aussagt, wie gut die Branche zugehört hat.
Die durchschnittliche Fehlererkennungsrate beträgt lediglich:
Im Gegensatz dazu liegt die durchschnittliche Effektivität von Design- und Codeinspektionen bei 55 % bzw. 60 % – eine wirklich beeindruckende Statistik. Natürlich funktioniert es nur dann, wenn das, was Sie im Peer-Review tun, effektiv und effizient ist.
Im Laufe der Jahre habe ich die vielen Fallstricke erlebt, die zu ineffektiven Peer-Reviews führen. Das Vermeiden dieser schlechten Gewohnheiten kann genauso effektiv sein wie das Annehmen guter neuer Gewohnheiten! Beseitigen Sie die unten aufgeführten schlechten Gewohnheiten, um ineffektive Peer-Reviews zu vermeiden.
Trotz der entscheidenden Rolle von Peer-Code-Reviews in der Softwareentwicklung sind sie nur dann sinnvoll, wenn sie effektiv und effizient durchgeführt werden. Ein schlecht durchgeführtes Peer-Review kann zu Zeitverschwendung führen, ohne dass hilfreiches Feedback zur Codeverbesserung gegeben wird. Um den Erfolg Ihres Code-Reviews zu gewährleisten, sollten Sie die folgenden acht Angewohnheiten vermeiden.
Zu Beginn sollten Sie nichts überprüfen oder suchen, was durch statische Analyse möglich ist. Dies kann Branding-Probleme, Stilprobleme wie die Platzierung von Locken umfassen {
Lass mich nicht anfangen;
},
oder mithilfe eines bestimmten Verschlüsselungsalgorithmus. Wenn ein Tool ihn für Sie finden kann, nutzen Sie es.
Im Zeitalter der LLMs gilt dies mehr denn je. Wenn Sie Ihre Überprüfungszeit mit etwas verbringen, das ein Modell in Sekundenschnelle erkennen könnte, verschwenden Sie die wertvollste Ressource im Raum: menschliches Urteilsvermögen.
Ein in Zusammenarbeit mit Claude erstellter Comic, der den Peer-Review-Prozess veranschaulicht.
Nehmen Sie sich die Zeit, den Algorithmus, die Sicherheits- und Leistungsmerkmale des Codes genauer zu untersuchen. Das ist eine lohnende Aufgabe und zudem viel interessanter.
Dies ist ein klassisches Problem, das insbesondere in kalenderzentrierten Organisationen häufig auftritt. Wenn Sie termingebunden veröffentlichen, ist die Wahrscheinlichkeit groß, dass Sie auch termingebunden überprüfen. Die Logik lautet: „Ich bin noch nicht fertig, aber wir haben bereits eine Überprüfung geplant, also schauen wir uns zumindest an, was wir haben.“ Sie wissen es genauso gut wie ich – das ist kein guter Weg für eine effektive Überprüfung, also hören Sie damit auf. Stellen Sie sicher, dass der Code-Autor fertig ist, und wenn er noch nicht fertig ist, verschieben Sie die Überprüfung, bis er es ist.
Langwierige Codeüberprüfungssitzungen können kontraproduktiv sein. Es ist wichtig, den Umfang und die Dauer jeder Überprüfung angemessen zu begrenzen, um den Fokus und die Produktivität aufrechtzuerhalten. Lange, ausführliche Überprüfungen können zu Ermüdung, verminderter Liebe zum Detail und einem langsameren Entwicklungsprozess führen.
Wenn die Überprüfung zu viel Zeit in Anspruch nimmt, müssen Sie etwas überdenken. Zu viel könnten in diesem Fall entweder Review-Sitzungen sein, die mehr als eine Stunde dauern, oder Sitzungen, die einen zu großen Teil des gesamten Entwicklungsplans in Anspruch nehmen. Wenn Rezensionen länger als eine Stunde dauern, versuchen Sie wahrscheinlich, zu viel auf einmal zu rezensieren. Oder der Autor war nicht bereit für die Rezension. Nach einer Stunde Überprüfung nimmt die potenzielle Wirksamkeit schnell ab, insbesondere für die Code-Autoren. Auch wenn der Kommentar anfangs nicht persönlich war, kann sich die Kritik nach einer unnötig langen Rezension verschärfen und schmerzhafter wirken.
Bei einem Peer-Review geht es um den Code, nicht um die Personen. Stellen Sie sicher, dass Sie über den Code sprechen, nicht über den Entwickler. Eine Aussage wie „Dieser Code skaliert nicht so gut, wie wir es brauchen“ ist weniger verletzend als „Das hast du schlecht geschrieben“. Umgekehrt: Seien Sie fair, wenn Sie Kritik einstecken müssen. Machen Sie sich bewusst, dass jeder Code verbessert werden kann und Sie aus den erhaltenen Daten lernen können. Egal, an welcher Stelle des Reviews Sie sich befinden, Sie können wahrscheinlich einen reibungslosen, angenehmen und schnellen Review-Prozess fördern. Betrachten Sie das Review als eine großartige Möglichkeit, einen kostenlosen Mentor zu finden. Jeder wünscht sich einen Mentor, aber wir betrachten den Review-Prozess selten als Mentoring-Prozess. Die Wertschätzung der Mentorschaft kann Ihnen helfen, sie nicht persönlich zu nehmen.
Es ist nicht nur eine Metapher für Neujahrsvorsätze. Ich bin wirklich der festen Überzeugung, dass die meisten Softwarequalitätspraktiken wie Übungen behandelt werden sollten. Wenn Sie versuchen, sie im letzten Moment zu überhäufen, werden sie nicht effektiv sein. Sie können am Abend vor einem Marathon nicht auf dem Laufband laufen und Sie können am Abend vor Ihrer Entlassung kein Peer-Review durchführen.
Das Problem bei Last-Minute-Reviews ist folgendes: Die Probleme, die man dann feststellt, sind selten solche, die man auch tatsächlich beheben kann.
Einfache Stilfehler? Ihr statisches Analysetool hat diese wahrscheinlich schon erkannt.
Namensfehler? LLMs erkennen die in Sekundenschnelle.
Was bei der Peer-Review in letzter Minute oft ans Licht kommt, sind die Dinge, die man in einem Sprint wirklich nicht mehr beheben kann – eine ungeeignete Framework-Wahl, eine Performance-Architektur, die nicht skalierbar ist, oder Sicherheitsannahmen, die bereits im Design verankert sind.
Das sind keine Fehler, die man über Nacht behebt. Es sind Entscheidungen, die man nur mit hohem Kostenaufwand rückgängig macht, wenn überhaupt. Überprüfen Sie Ihre Software früh genug, damit Sie auf die gefundenen Fehler auch tatsächlich reagieren können. Ein grundlegendes Problem erst am Abend vor der Veröffentlichung zu entdecken, ist keine erfolgreiche Überprüfung – es ist lediglich eine teure Bestätigung dafür, dass Sie zu lange gewartet haben.
Wie eine Bewertung weiterverfolgt wird, kann großen Einfluss auf den Wert der Bewertung haben. Wenn Sie während einer Überprüfung Elemente finden und nicht überprüfen, ob diese behoben sind, verschwenden Sie wahrscheinlich Ihre Zeit. Der größte Nutzen liegt in einem konsistenten Prozess, der die Verantwortlichkeit einschließt. Stellen Sie sicher, dass jeder weiß, was von ihm erwartet wird, und stellen Sie sicher, dass Korrekturen vorgenommen werden.
Achten Sie auf Muster in Ihren Review-Ergebnissen. Wenn eine bestimmte Codebasis, ein bestimmter Entwickler oder ein bestimmter Zeitpunkt im Zeitplan regelmäßig Reviews ohne Befunde liefert, ist das ein Hinweis, dem Sie nachgehen sollten. Das ist keine Aufforderung, Fehler zu erfinden, sondern ein Anlass, nach den Gründen zu fragen.
Ich habe Entwickler erlebt, die sich gegenseitig den Code in einer perfekt organisierten, partnerschaftlichen Abfolge geprüft haben: Probleme wurden erfasst, behoben, nichts blieb unvollendet, alles wurde mit unglaublicher Effizienz abgeschlossen. Unglaublich effizient. Wirklich unglaublich.
Leere Bewertungen sind kein Beweis für perfekten Code. Sie sind oft ein Beweis für einen fehlerhaften Bewertungsprozess.
Wenn nicht jeder Rezensent nach den gleichen Dingen sucht, haben Sie keine Ahnung, ob Ihre Bewertungen effektiv sind. Der Umfang des Peer-Reviews muss auf einer eindeutigen Richtlinie basieren, die klar niedergeschrieben ist und auf die verwiesen werden kann. Eine Checkliste mag auf den ersten Blick einengend wirken, aber sie hilft dabei, die Überprüfung auf Kurs zu halten und erfüllt eine doppelte Aufgabe, wenn Sie in einer Compliance-Branche wie der Automobil- oder Medizinbranche tätig sind und nachweisen müssen, dass Sie eine effektive Überprüfung durchgeführt haben.
Die Beseitigung von Unklarheiten erfordert mehr Disziplin als nur das Aufschreiben der Richtlinie, obwohl dies ein guter erster Schritt ist. Im Idealfall würden Sie ein paar Szenarien basierend auf Ihrer Richtlinie konkretisieren und verschiedene Personen fragen, wie sie es tun würden. Es ist nicht ungewöhnlich, dass Unternehmen einen Status Quo akzeptieren, bei dem verschiedene Gruppen die Dinge unterschiedlich machen und beide denken, dass die andere Gruppe es falsch macht, aber beide werden im Rahmen der unklaren Richtlinie zugelassen. Das kannst du besser.
Bringen Sie alle auf den gleichen Stand. Es verbessert Ihre Qualität, bietet die für die Beurteilung und Verbesserung erforderliche Konsistenz und schützt Sie, wenn etwas schief geht. Wenn Sie sich in einer Compliance-Umgebung wie ISO 26262 oder FDA befinden, werden einheitliche Kriterien Ihre Audits rationalisieren.
Ich habe Peer-Reviews in den unterschiedlichsten Organisationen miterlebt und gesehen, wo sie unglaublich wertvoll sein können, aber auch, wo sie reine Zeitverschwendung sind. Und das war noch vor der Einführung des LLM-Programms.
LLMs sind mittlerweile fester Bestandteil der Diskussion um Code-Reviews, unabhängig davon, ob Ihre Organisation diesbezüglich eine formale Richtlinie hat oder nicht. Das hat Vor- und Nachteile.
Es lohnt sich, beide Fehlermodi zu kennen.
Einer der praktischsten Anwendungsbereiche von LLMs ist derzeit die erste Überprüfung des Codes, bevor er einem menschlichen Prüfer vorgelegt wird. Man kann es sich wie das laute Vorlesen einer E-Mail vor dem Absenden vorstellen.
Wenn man einen LLM bittet, den Diff zu überprüfen – und dabei nach logischen Fehlern, unklarer Benennung, fehlenden Sonderfällen oder Stellen sucht, an denen die Absicht nicht mit der Implementierung übereinstimmt –, werden peinliche Dinge aufgedeckt, bevor sie die Zeit eines Kollegen verschwenden.
Das hilft auch bei Gewohnheit Nr. 3. Wenn Sie in eine 45-minütige Besprechung gehen und das LLM bereits drei von Ihnen behobene Punkte markiert hat, ist die Besprechung kürzer und fokussierter. Davon profitieren alle Beteiligten.
Seien Sie daher präzise in Ihrer Anfrage. „Überprüfen Sie meinen Code“ ist eine ungenaue Aufforderung.
„Überprüfen Sie diese Funktion auf Lücken in der Fehlerbehandlung und markieren Sie alles, was den Anschein erweckt, als würde sie von korrekten Eingaben ausgehen.“ LLMs reagieren auf den Gültigkeitsbereich. Sie können sich unberechenbar ausbreiten, wenn man sie lässt.
LLMs sind selbstsichere Gutachter, was Teil des Problems ist. Sie geben autoritär klingendes Feedback zu Code, den sie grundlegend missverstehen – insbesondere wenn der Kontext begrenzt ist, die Codebasis groß ist oder die Logik auf Domänenwissen beruht, das in der Aufgabenstellung nicht erwähnt wurde.
Behandeln Sie ihre Ergebnisse so, wie Sie das Feedback eines klugen Praktikanten am ersten Tag behandeln würden: nützlich für offensichtliche Dinge, unzuverlässig für alles Subtile.
Einige spezifische Fehlermodi, auf die Sie achten sollten:
Richtig eingesetzt, steigern LLMs die Effektivität menschlicher Gutachter, indem sie die offensichtliche Vorarbeit leisten. Unachtsam eingesetzt, erzeugen sie den Anschein von Strenge ohne Substanz. Das ist in jedem Entwicklungskontext ein schlechter Tausch und bei sicherheitskritischen Arbeiten potenziell schwerwiegend.
Zusammenfassend lässt sich sagen, dass Peer-Code-Reviews ein immenses Potenzial besitzen, den Softwareentwicklungsprozess zu verbessern und die Bereitstellung qualitativ hochwertiger Software sicherzustellen.
Für Entwickler bietet die Teilnahme an effektiven Code-Reviews unter Kollegen mehrere entscheidende Vorteile. Sie erhalten dadurch wertvolle Lernmöglichkeiten, indem sie verschiedene Programmierstile, Best Practices und unterschiedliche Problemlösungsansätze innerhalb ihres Teams kennenlernen. Dieser Wissensaustausch fördert die berufliche Weiterentwicklung und den Kompetenzaufbau. Darüber hinaus helfen Code-Reviews unter Kollegen Entwicklern, Fehler frühzeitig zu erkennen und zu beheben sowie die Konsistenz und Wartbarkeit der Codebasis zu verbessern.
Zur Unterstützung erfolgreicher Code-Review-Prozesse kann der Einsatz statischer Analysetools von unschätzbarem Wert sein. Diese Tools analysieren den Code automatisch auf potenzielle Probleme wie Verstöße gegen Codierungsstandards, Sicherheitslücken und Code-Smells.
Für C, C++, Java, C# und VB.NET bietet Parasoft statische Codeanalyse-Tools wie C/C++test , Jtest und dotTEST an . Alle diese Tools verfügen über KI- und ML-Funktionen und sind für verschiedene Entwicklungsumgebungen konzipiert. Durch die Integration statischer Analysetools in den Code-Review-Workflow können Teams die Effizienz und Effektivität ihrer Reviews steigern. Die Kombination der Expertise von Peer-Reviewern mit der Automatisierung durch statische Analysetools optimiert den Wert und die Wirkung von Peer-Code-Reviews im Softwareentwicklungszyklus.
Erfahren Sie mehr darüber, wie Sie KI in Ihre Testabläufe integrieren können.
