Was ist die effektivste Methode, um Codeüberprüfungen durchzuführen? [geschlossen]

71

Ich habe noch nie den idealen Weg gefunden, um Codeüberprüfungen durchzuführen, und dennoch fordern meine Kunden sie oft. Jeder Kunde scheint sie auf eine andere Art und Weise zu tun und ich habe mich in keinem von ihnen zufrieden gefühlt.

Was war für Sie die effektivste Methode, um Codeüberprüfungen durchzuführen?

Zum Beispiel:

  • Wird eine Person als Gatekeeper für Qualität und Überprüfung des Codes angesehen oder besitzt das Team den Standard?
  • Überprüfen Sie Code als Teamübung mit einem Projektor?
  • Erfolgt dies persönlich, per E-Mail oder mithilfe eines Tools?
  • Vermeiden Sie Überprüfungen und verwenden Sie Dinge wie Pair Programming und Collective Code Ownership, um die Codequalität sicherzustellen?
Paddyslacker
quelle
Smart Bear Software hat ein kostenloses Buch mit dem Titel Best Kept Secrets of Peer Code Review . Und währenddessen erhalten sie gelegentlich eine E-Mail mit den Verkäufen. Sie waren kaum aufdringlich. Und übrigens ... das Buch ist ziemlich gut.
John MacIntyre

Antworten:

32

Bei meiner Arbeit haben wir eine sehr einfache Regel: Änderungen müssen von mindestens einem anderen Entwickler überprüft werden, bevor sie zusammengeführt oder in den Trunk übernommen werden . In unserem Fall bedeutet dies, dass die andere Person physisch mit Ihnen an Ihrem Computer sitzt und die Änderungsliste durchläuft. Dies ist kein perfektes System, aber es hat trotzdem die Codequalität merklich verbessert.

Wenn Sie wissen, dass Ihr Code überprüft wird, müssen Sie ihn zuerst überprüfen. Dann werden viele Probleme offensichtlich. In unserem System müssen Sie dem Prüfer erklären, was Sie getan haben, was wiederum dazu führt, dass Sie Probleme bemerken, die Sie möglicherweise zuvor übersehen haben. Auch wenn dem Prüfer etwas in Ihrem Code nicht sofort klar ist, ist dies ein gutes Indiz dafür, dass ein besserer Name, ein Kommentar oder ein Refactoring erforderlich sind. Und natürlich kann der Rezensent auch Probleme finden. Zusätzlich zur Überprüfung der Änderung kann der Prüfer auch Probleme im Code in der Nähe feststellen.

Dieses System weist zwei Hauptnachteile auf. Wenn die Änderung trivial ist, macht es wenig Sinn, sie überprüfen zu lassen. Wir müssen uns jedoch unbedingt an die Regeln halten, um zu vermeiden, dass Änderungen als "trivial" deklariert werden, wenn dies nicht der Fall ist. Auf der anderen Seite ist dies keine sehr gute Möglichkeit, wesentliche Änderungen am System oder das Hinzufügen großer neuer Komponenten zu überprüfen.

Wir haben zuvor formellere Überprüfungen versucht, bei denen ein Entwickler einen Code per E-Mail an den Rest des Teams weiterleitete und dann das gesamte Team zusammenkam und darüber diskutierte. Dies hat viel Zeit in Anspruch genommen, und infolgedessen gab es nur wenige Überprüfungen, und nur ein kleiner Prozentsatz der Codebasis wurde überprüft. Die "eine andere Person überprüft Änderungen vor dem Festschreiben" hat für uns viel besser funktioniert.

Dima
quelle
Sehr nützlich, danke! Ich bereite die Sessions meines eigenen Teams vor und denke, das könnte ein guter Ansatz sein.
Neonigma
13

Ich mag Code-Reviews, obwohl sie einen Schmerz darstellen können. Der Grund, warum ich sie mag, ist, dass sie mehr Augen auf den Code und eine andere Perspektive bekommen. Ich glaube, dass auch bei der Paarprogrammierung Code überprüft werden sollte. Es ist einfach genug, dass zwei Personen, die an demselben Code arbeiten, gemeinsam den gleichen Fehler machen, den ein anderer Satz von Augen möglicherweise nicht übersieht.

Wenn Sie als Gruppe mit einem Projektor arbeiten, sollten Sie dies vor dem Meeting unbedingt einzeln überprüfen . Ansonsten ist es nur eine nervige Zeitverschwendung.

Ich habe nur Code-Reviews per E-Mail und in einer Gruppe durchgeführt. Im Allgemeinen denke ich nicht, dass sie persönlich gemacht werden sollten. Sie haben ein wenig mehr Druck, sich mit jemandem, der Ihnen über die Schulter schaut, durch den Code zu stürzen. Ich bin der Meinung, dass ein Tool für die Codeüberprüfung ein guter Vorteil ist, da es bei einigen der alltäglichen Aspekte hilfreich sein kann und das Markieren problematischer Code-Teile einfacher machen sollte als per E-Mail.

Das Problem, wenn nur eine Person alle Codeüberprüfungen durchführt, ist, dass dies ein Engpass sein kann. Mit gut dokumentierten und entworfenen Kodierungsstandards sollte es nicht notwendig sein. Abhängig von der Umgebung / dem Release-Zeitplan kann es eine gute Idee sein, immer jemanden als Überprüfer des Standby-Codes zu haben.

Ich glaube, dass der Besitz von Code eine gute Idee ist, da diese Person es zu ihrer Priorität machen kann, diesen Code zu verstehen und möglicherweise eine Gatekeeper-Rolle zu spielen.

George Marian
quelle
+1 für "Wenn Sie als Gruppe mit einem Projektor arbeiten, sollten Sie dies vor dem Meeting unbedingt einzeln überprüfen. Andernfalls ist dies nur ärgerliche Zeitverschwendung."
AShelly,
1
"Wenn Sie als Gruppe mit einem Projektor arbeiten, ist dies eine ärgerliche Zeitverschwendung."
gbjbaanb
Wenn du es persönlich machst, ist es ein anderer Prozess. Du überprüfst nicht den Code des anderen, während er dir über die Schulter schaut. Er erklärt Zeile für Zeile, was er geändert hat, was seine Änderungen bewirken und warum, während Sie ihm zuhören. Es übt den Druck auf denjenigen aus, der den Code erstellt hat, um ihn zu erklären, und nicht auf Sie, um ihn zu verstehen und zu überprüfen.
Didier A.
6

Bei SmartBear erstellen wir nicht nur ein Tool zur Codeüberprüfung , sondern verwenden es auch täglich. Es ist ein wesentlicher Bestandteil unseres Entwicklungsprozesses. Wir überprüfen jede Änderung, die eingecheckt wird.

Ich halte es aus vielen Gründen für eine schlechte Idee, einen einzigen Gatekeeper-Code-Prüfer zu haben. Diese Person wird zu einem Engpass und muss zu viel Code überprüfen (nur um das Projekt am Laufen zu halten), um wirklich effektiv zu sein (60-90 Minuten auf einmal sind die Grenze der Effektivität). Code Reviews sind eine großartige Möglichkeit, Ideen und Wissen auszutauschen. Egal, wie sehr Ihr Gatekeeper ein Superstar ist, er kann von anderen Teammitgliedern lernen. Wenn jeder Code-Überprüfungen durchführt, entsteht auch eine Umgebung mit "kollektivem Code-Besitz", in der die Leute das Gefühl haben, die Qualität des Codes zu besitzen (es geht nicht nur um die Qualitätssicherung oder den Gatekeeper).

Wir haben ein kostenloses Whitepaper zu " Best Practices für Peer Code Review " mit 11 Tipps, mit denen Sie Code Reviews effektiv durchführen können. Vieles davon ist derselbe Inhalt aus dem Buch, das John in einer destillierteren Form erwähnt hat.

Brandon DuRette
quelle
1
Link down ...........
Pacerier
Entschuldigung für den Link rot. Ich habe die aktuelle URL bearbeitet, aber das wird nicht verhindern, dass sie erneut auftritt.
Brandon DuRette
3

Keine Entschuldigung. Übe das Programmieren von Paaren. Es ist die bestmögliche Codeüberprüfung. Jeder andere Mechanismus führt zu Schuldzuweisungen. Paarprogrammierung fördert Teamgeist und kollektive Eigenverantwortung. Darüber hinaus diskutieren Sie Ihre Ideen mit Ihrem Paar, scheitern schnell, ergreifen Korrekturmaßnahmen und es wird nur der paarweise codierte und überprüfte Code in das Configuration Management System (CMS) übernommen. Happy-Pair-Programmierung!

Karthiks
quelle
Ich stimme vollkommen zu. Die Paarprogrammierung stellt sicher, dass die Codequalität beim Schreiben überprüft wird. Wenn Sie TDD einführen, erhalten Sie getesteten, qualitätskontrollierten Code, der in einem Feature-Zweig veröffentlicht wird. Testen Sie die Funktionen in der Verzweigung gegen separat geschriebene QS-Tests. Zusammenführen, um zu meistern. Sauberer Code, sauberer Master.
Dooburt
Pair-Programmierung funktioniert nicht für einen sehr großen Prozentsatz der Software-Entwickler, und ich wage zu sagen, dass es wahrscheinlich die besten Entwickler ausschließt. Die meisten SW-Entwickler beschäftigen sich mit Computerprogrammierung, weil sie introvertiert sind, was bedeutet, dass sie es vorziehen, mehr mit Computern als mit Menschen zu arbeiten. Ich für meinen Teil muss in die "Zone", um effektiv zu sein, und das bedeutet "stört mich nicht". Lass mich in meiner Zone und ich mache die Arbeit von 4 oder 5 anderen Entwicklern und dann von einigen.
Dunk
2

Wenn Sie an einem Projekt arbeiten, bei dem mehrere Personen zur Codebasis beitragen, muss ein Standard erstellt werden.

Nach meiner Erfahrung ist es an dieser Stelle am besten, eine Person als "König" der Codeüberprüfung zu bestimmen, wenn Sie so wollen und was sie sagt. In dieser Hinsicht kümmert sich der König darum, wenn ein Benutzer die Standards nicht einhält.

Als Entwickler überprüfe ich meinen eigenen Code viele Male, um lesbar, vernünftig und alles andere zu sein. Normalerweise verwenden wir Javadoc oder ähnliches in bestimmten Sprachen, mit denen wir codieren, und verwenden das @author-Tag, um Funktionen, Klassen usw. als Eigentümer zuzuweisen.

Wenn eine Funktion nicht korrekt ist, sprechen wir mit dem Eigentümer, ebenso mit der Klasse usw.

Chris
quelle
2

In meiner Firma wird jeder Aufgabe ein Tester zum Testen der Aufgabe sowie ein Code-Prüfer zum Überprüfen des Codes zugewiesen.

Wenn Ihr Produkt bereits freigegeben ist und Sie sicherstellen möchten, dass Sie nichts falsch machen (z. B. ein Handle-Leck oder ein Speicherverlust), sind Codeüberprüfungen eine großartige Sache. Ich denke, während der anfänglichen Entwicklung vor der Veröffentlichung Ihres Produkts sind Code-Überprüfungen möglicherweise zu aufwändig.

Wenn Ihr Team nur leitende Entwickler hat, ist Peer Review dennoch nützlich. Jeder macht manchmal Fehler. Wenn Ihr Team einige Senioren und einige Junioren hat, lassen Sie die Senior-Entwickler die Codeüberprüfungen durchführen, haben aber immer noch Codeüberprüfungen für den Code des Senioren.

Eine wichtige Sache bei der Codeüberprüfung ist, dass sie Fehler auffangen kann, die wir machen, aber sie ist kein Ersatz für das Testen.

Brian R. Bondy
quelle
2

Ich empfehle die Verwendung von Code Reviews, wenn Sie keine Paarprogrammierung durchführen.

Nicht um die Vor- und Nachteile von Pairing zu streiten, aber es ist schwer zu bestreiten, dass Ihr Code ständig (zumindest) von einer anderen Person überprüft wird. Der Code wird sogar von (mindestens) zwei Programmierern geschrieben und entworfen - besser geht es kaum. Ich sage "zumindest", weil imo, Sie sollten versuchen, Paare viel zu wechseln, damit jeder einen Versuch bekommt, mit dem Code zu arbeiten.

Martin Wickman
quelle
2

In den Code-Überprüfungen, an denen ich teilnehme, versuche ich unter anderem, den Code selbst zu überprüfen, den Code statisch zu analysieren, Tools wie Findbugs, PMD, JavaNCCP usw. zu verwenden und Probleme zu untersuchen, die diese Tools enthalten der Code, der überprüft werden soll. Ich möchte insbesondere alles untersuchen, was einen ungewöhnlich hohen Grad an Komplexität aufweist, und sie bitten, zu erklären, warum dieser Grad an Komplexität erforderlich ist oder warum die vorgeschlagene Sicherheitsanfälligkeit nicht wichtig ist.

YMMV

Mezmo
quelle
2

Wo ich derzeit arbeite, stellen wir Hardwaregeräte und die damit verbundene Software her, die in die kritische Infrastruktur eingehen. Aus diesem Grund legen wir großen Wert auf die Release-Qualität. Wir verwenden eine Variante von Fagan Inspection und führen einen formellen Überprüfungsprozess durch. Wir sind unter anderem nach ISO 9001 zertifiziert.

Die kritische Infrastrukturbranche ist sehr an Zuverlässigkeit und Wiederholbarkeit interessiert. :-)

Paul Nathan
quelle
2

In meiner Firma gibt es obligatorische Code-Reviews für Junior-Programmierer und freiwillige Reviews für Senioren. Es gibt keinen festgelegten Code-Prüfer. Überprüfungsanfragen werden an alle Entwickler gesendet.

Dieses System funktioniert gut - Überprüfungen werden durchgeführt, wenn es die Zeit erlaubt, und Änderungen können von mehreren Augapfelsätzen überprüft werden.

Das ausgezeichnete und kostenlose Review Board- Tool funktioniert sehr gut für uns und hat sich als hervorragende Methode zur Übermittlung von Bewertungen erwiesen.

GavinH
quelle
2
freiwillige Bewertungen für Senioren. Ich habe an mehreren Projekten gearbeitet, in denen erfahrene Programmierer auf jeden Fall Code-Reviews verwenden könnten ...
Michel
1

In meinem Unternehmen führen wir vor dem Einchecken keine formellen Codeüberprüfungen durch, es sei denn, wir ändern eine hochkritische Produktion und haben nicht die Zeit, unseren Standard-QS-Prozess durchzuführen.

Was wir tun, ist, dass jedes Mal, wenn wir der Meinung sind, dass eine Codeüberprüfung nützlich wäre, wir dem geänderten Code einen Kommentar "// todo: code review by joe" hinzufügen. Normalerweise wählen wir Joe aus, weil er den geänderten Code besitzt. Wenn dieses Auswahlkriterium jedoch nicht zutrifft (normalerweise), wählen wir zufällig einen anderen aus. Und falls Joe zu diesem Zeitpunkt verfügbar sein sollte, verwenden wir natürlich die gute alte Methode der Überprüfung über die Schulter.

Als Prüfer müssen Sie nur regelmäßig den gesamten Code nach "// todo: code review by me" durchsuchen , die Änderungen überprüfen und den Code ohne den Kommentar "todo ..." erneut einchecken

Wenn es ein Problem gibt, wechseln wir zu herkömmlichen Kommunikationsmethoden (Mail / Chat / etc).

Diese Methode bietet uns die zwei Hauptqualitäten, die wir in einem Überprüfungssystem suchen:

  • sehr leichter Overhead
  • Rückverfolgbarkeit
Brann
quelle
1

Wir finden, dass die effektivste Methode zur Codeüberprüfung 1-zu-1 mit github ist, um die Unterschiede in der Branche aufzuzeigen.


  • Wird eine Person als Gatekeeper für Qualität und Überprüfung des Codes angesehen oder besitzt das Team den Standard?

    • Hängt von der Größe des Teams ab - in einem 3-köpfigen Team gibt es einen Senior mit den besten Kenntnissen über bewährte Praktiken, während in einem 12-köpfigen Team 3 oder 4 Personen diese Rolle übernehmen.
  • Überprüfen Sie Code als Teamübung mit einem Projektor?

    • Persönlich. 1 gegen 1, um weniger bedrohlich zu sein. Manchmal wird es im Gemeinschaftsbereich gemacht, um das Wissen zu verbreiten. Hängt von der genauen Situation, den Personen, dem Zeitplan usw. ab.
  • Erfolgt dies persönlich, per E-Mail oder mithilfe eines Tools?

    • Persönlich. Wir verwenden Git und Github und es verfügt über großartige Tools zur Codeüberprüfung und zum Vergleichen von Unterschieden, um die Codeüberprüfung zu vereinfachen.
  • Vermeiden Sie Überprüfungen und verwenden Sie Dinge wie Pair Programming und Collective Code Ownership, um die Codequalität sicherzustellen?

    • Wir versuchen, beides angemessen zu machen. Dies bedeutet, dass bei einem besonders heiklen Problem, bei der Arbeit an der Kerninfrastruktur oder bei der Vorbereitung auf den Urlaub oder beim Verlassen des Unternehmens möglicherweise ein Pairing durchgeführt werden kann, um Wissen auszutauschen und zu übertragen. Die meisten Codes oder Codes, die mehr als kosmetische Änderungen enthalten, sollten am Ende ebenfalls überprüft werden.

Wie bei allen Codierungselementen sollte die richtige Antwort Folgendes berücksichtigen:

  • Art des Unternehmens (zB Startup vs. Großunternehmen)
  • Firmengröße
  • Anzahl der Entwickler
  • Budget
  • Zeitrahmen
  • Arbeitsbelastung
  • Komplexität des Codes
  • Fähigkeit der Gutachter
  • Verfügbarkeit der Prüfer
Michael Durrant
quelle
0

Ich habe in vielen Unternehmen gearbeitet und viele Prozesse gesehen. Mein derzeitiges Team geht damit am besten um, was ich bisher gesehen habe.

Wir verwenden einen agilen Entwicklungsprozess und als Teil davon haben wir Tore, die jede Geschichte durchlaufen muss. Eines dieser Tore ist die Codeüberprüfung. Die Geschichte wird erst getestet, wenn die Codeüberprüfung abgeschlossen ist.

Zusätzlich speichern wir unseren Code unter github.com. Nachdem ein Entwickler seine Änderung abgeschlossen hat, veröffentlicht er den Link zu den Commits in der Story.

Dann markieren wir einen Mitentwickler zur Überprüfung. Github verfügt über ein Kommentarsystem, mit dem jemand direkt in der betreffenden Codezeile Kommentare abgeben kann. Github schickt dann eine E-Mail an die Distribution, so dass wir manchmal zusätzliche Augen von einigen unserer anderen Teams bekommen.

Dieser Prozess hat bei uns sehr gut funktioniert. Wir verwenden ein agiles Prozesstool, mit dem das Veröffentlichen von Commits einfach und die Kommunikation erleichtert wird.

Wenn ein Thema besonders schwierig ist, setzen wir uns zusammen und besprechen es. Dies funktioniert, weil es ein wesentlicher Bestandteil unseres Prozesses ist und jeder die Funktionsweise des Prozesses mit einbezieht. Wir können Tickets wieder in den Status "In Bearbeitung" versetzen, wenn die Codeüberprüfung die erforderliche Überarbeitung zur Folge hat. Sie können dann nach Änderungen erneut überprüft werden, oder der Überprüfer merkt in der Story an, dass das Reparieren der Elemente ausreichend ist und nicht erneut überprüft werden muss.

Wenn das Testen etwas zurückwirft, wird es bis zum aktuellen Stand fortgesetzt, und alle weiteren Änderungen werden ebenfalls überprüft.

Bill Leeper
quelle