it-swarm.com.de

Wie kann ich bessere Codeüberprüfungen durchführen, wenn Pull-Anfragen groß sind?

Haftungsausschluss : Es gibt einige ähnliche Fragen, aber ich habe keine gefunden, die speziell die Probleme berühren, mit denen Sie beim Überprüfen einer großen Pull-Anfrage konfrontiert sind.

Problem

Ich bin der Meinung, dass meine Codeüberprüfungen besser durchgeführt werden könnten. Ich spreche insbesondere von großen Codeüberprüfungen mit vielen Änderungen in mehr als 20 Dateien.

Es ist ziemlich einfach, offensichtliche Probleme mit dem lokalen Code zu erkennen. Zu verstehen, ob der Code die Geschäftskriterien erfüllt, ist eine andere Geschichte.

Ich habe Probleme, dem Gedankenprozess des Code-Autors zu folgen. Es ist ziemlich schwierig, wenn die Änderungen zahlreich sind und sich auf mehrere Dateien verteilen. Ich versuche mich auf die Gruppen von Dateien zu konzentrieren, die sich auf eine bestimmte Änderung beziehen. Überprüfen Sie dann die Gruppen nacheinander. Leider ist das von mir verwendete Tool (Atlassian Bitbucket) nicht sehr hilfreich. Wenn ich eine Datei besuche, wird sie als gesehen markiert, obwohl sich häufig herausstellt, dass sie nicht mit den aktuell untersuchten Änderungen zusammenhängt. Ganz zu schweigen davon, dass einige Dateien mehrmals besucht und ihre Änderungen Stück für Stück überprüft werden sollten. Es ist auch nicht einfach, zu relevanten Dateien zurückzukehren, wenn Sie einem schlechten Pfad folgen.

Mögliche Lösungen und warum sie bei mir nicht funktionieren

Das Überprüfen einer Pull-Anfrage durch Commits löst häufig die Größenprobleme, aber ich mag es nicht, da ich häufig veraltete Änderungen betrachte.

Natürlich scheint das Erstellen kleinerer Pull-Anfragen eine Abhilfe zu sein, aber es ist das, was es ist. Manchmal erhalten Sie eine große Pull-Anfrage und diese muss überprüft werden.

Sie können auch den logischen Aspekt des Codes als Ganzes ignorieren, aber es scheint ziemlich riskant zu sein, insbesondere wenn der Code von einem unerfahrenen Programmierer stammt.

Die Verwendung eines besseren Tools könnte hilfreich sein, aber ich habe keines gefunden.

Fragen

  • Haben Sie ähnliche Probleme mit Ihren Codeüberprüfungen? Wie begegnen Sie ihnen?
  • Vielleicht haben Sie bessere Werkzeuge?
12
Andrzej Gis

Wir hatten diese Probleme und die folgende Frage zu stellen hat für uns gut funktioniert:

Tut die PR eine Sache, die zusammengeführt und unabhängig getestet werden kann?

Wir versuchen, PRs durch Single Responsibility (SR) zu brechen. Nach dem ersten Push-Back waren die Leute überrascht, dass sogar etwas klein, wenn auch einzeln groß sein kann.

Die SR macht es wirklich einfach zu überprüfen und verbreitet auch Wissen über die erwartete Implementierung.

Dies ermöglicht auch inkrementelle Refaktoren, da mehr hinzugefügt werden und die PR-Bearbeitungszeit drastisch reduziert wird!

Ich würde vorschlagen, sie nach Möglichkeit nach SR aufzubrechen und zu prüfen, ob sie für Sie funktionieren. Es braucht etwas Übung, um es so zu machen.

8
PhD

Manchmal können Sie große Pull-Anfragen nicht vermeiden - aber Sie können erkennen, wer welche Verantwortung hat.

Ich behandle Pull-Anfragen als überzeugende Argumente. Der Autor versucht mich davon zu überzeugen, dass der Code so aussehen und funktionieren sollte.

Wie bei jedem Argument sollte es eine einzige klare Idee haben. Es ist entweder:

  • ein Refaktor,
  • eine Optimierung,
  • oder neue Funktionalität.

Wenn sie nicht klar sind, besteht eine ziemlich gute Chance, dass sie es selbst nicht verstehen. Öffnen Sie den Dialog und helfen Sie ihnen, ihre Argumentation in ihre Unterargumente zu zerlegen. Wenn es sein muss, ist es vollkommen in Ordnung - sogar für sie von Vorteil, diese Commits neu zu erstellen und verständlichere und direktere Pull-Anfragen anzubieten.

Es wird immer noch große Pull-Anfragen geben, aber mit einem klaren Argument ist es viel einfacher zu erkennen, was nicht passt.

Die Werkzeuge hängen von Ihrer Organisation und Ihrem Prozess ab. BitBucket ist ein anständiges Tool, ob es besser ist oder nicht, hängt von Ihrem Budget, Ihrer Hardware, Ihren Anforderungen bis zu Ihren bereits vorhandenen Prozessen, Geschäftsregeln und verschiedenen Software-Anpassungen ab, die Sie bereits vorgenommen haben, um BitBucket zu unterstützen. Ich würde zunächst in der Dokumentation nachsehen, ob das Verhalten konfiguriert werden kann, und es möglicherweise an die Plugin-Community weiterleiten (oder sich daran anschließen, indem ich ein Plugin dafür erstelle).

11
Kain0_0

Überprüfen Sie nicht die vollständige Pull-Anforderung, sondern jedes Commit. Auf diese Weise erhalten Sie ohnehin ein besseres Verständnis für die Pull-Anforderung.¹

Wenn die Commits gering sind, sollte eine solche Überprüfung kein Problem darstellen. Sie verfolgen die Änderungen nacheinander durch die Commits und erhalten am Ende das vollständige Bild. Es gibt Nachteile, wie zum Beispiel, dass Sie manchmal Änderungen überprüfen, die einige Commits später rückgängig gemacht werden, aber dies sollte nicht viel sein.

Wenn die Commits groß sind, sollten Sie dies mit der Person besprechen, die diese Commits durchgeführt hat. Erklären Sie ihm, warum große Commits problematisch sind. Hören Sie sich die Argumente der anderen Person an, warum sie Änderungen selten festschreibt: Sie können beispielsweise feststellen, dass sie Festschreibungen vermeidet, weil Hooks vor dem Festschreiben zu lange dauern. In diesem Fall sollte dieses Problem zuerst gelöst werden.

Das Überprüfen einer Pull-Anfrage durch Commits löst häufig die Größenprobleme, aber ich mag es nicht, da ich häufig veraltete Änderungen betrachte.

Sie tun dies, aber dies ist ein kleines Problem, und Sie sollten viel weniger Zeit damit verschwenden, Code zu überprüfen, der einige Commits später rückgängig gemacht wird, als wenn Sie versuchen, herauszufinden, warum der Code beim Überprüfen einer einzelnen Datei geändert wurde.

"Häufig" ist vage, aber wenn Sie zu viel Zeit damit verbringen, Code zu überprüfen, der nicht zur endgültigen Überarbeitung der Pull-Anforderung gelangt ist, können Sie zwei Techniken verwenden:

  • Gehen Sie alle Commits einmal schnell durch und lesen Sie einfach die Commit-Nachrichten. Auf diese Weise können Sie sich beim Studium eines bestimmten Commits daran erinnern, dass eine Commit-Nachricht irgendwo später besagt, dass die Änderung, die Sie sich ansehen, rückgängig gemacht wurde.

  • Sehen Sie sich die neueste Version der Datei nebeneinander an (obwohl in vielen Fällen bei großen Commits (1) die Dateien radikal unterschiedlich sein können und (2) die Dateien möglicherweise umbenannt werden oder die großen Codeblöcke an einen anderen Ort verschoben werden, was es schwierig macht, die passende Datei zu finden).

  • Bitten Sie die Committer entweder, Commits zu quetschen, wenn dies sinnvoll ist, oder haben Sie bestimmte Konventionen für Commit-Nachrichten, bei denen ein Commit einen Teil eines anderen rückgängig macht, und führen Sie Ihre Überprüfung unter Berücksichtigung mehrerer nachfolgender Commits durch.


¹ Stellen Sie sich zum Beispiel vor, Sie betrachten eine Datei, in der eine Variable umbenannt wurde. Was sagt es dir? Wie sollten Sie diese Änderung überprüfen? Wenn Sie jedoch Commit für Commit überprüfen, werden Sie feststellen, dass ein einzelnes Commit dieselbe Variable in zwanzig Dateien umbenannt hat. Der Kommentar gibt an, dass der Name geändert wurde, um den richtigen Geschäftsbegriff zu verwenden. Diese Änderung ist absolut sinnvoll und kann überprüft werden.

8

Finden Sie heraus, was Sie mit Überprüfungen von Pull-Anfragen erreichen möchten, und prüfen Sie, ob es eine Alternative gibt.

Zum Beispiel möchten Sie vielleicht

  • Stellen Sie sicher, dass die Standards eingehalten werden
  • Überprüfen Sie, ob die Funktionalität korrekt ist
  • Stellen Sie sicher, dass mehr als eine Person den Code versteht
  • Junioren trainieren

etc etc. etc.

Einige davon können durch andere Dinge besser bedient werden, und selbst wenn Sie nur die Gründe verstehen, können Sie den Umfang Ihrer Überprüfungen einschränken.

Wenn ich zum Beispiel jede Zeile überprüfe, um Änderungen für das Training vorzuschlagen und zu diskutieren, kann ich dies bei großen PRs von Senioren überspringen

Wenn ich den Code verstehen muss, führen Sie möglicherweise eine Paarprogrammierung für große Funktionen durch und beschränken Sie die Codeüberprüfung auf eine Standardprüfung.

Sie müssen nicht alle Dinge in jeder PR überprüfen, solange Sie einen mehrschichtigen Ansatz für die Qualitätssicherung haben

2
Ewan