Programmiersprachen git

Pull Request - Best Practices

Ein Pull Request (PR) ist ein zentraler Bestandteil des kollaborativen Entwicklungsprozesses. Bevor ein PR in das Hauptprojekt integriert (gemerged) wird, sollten die Änderungen sorgfältig überprüft werden, um Fehler zu vermeiden, den Code zu verbessern und die Qualität des Projekts zu sichern.


3 Minuten Lesezeit
13 Okt 2024
documents/git_tIsE847.jpg

Was lerne ich in diesem Kurs?

In diesem Tutorial wird erklärt, wie ein Pull Request effektiv überprüft wird und welche Best Practices dabei beachtet werden sollten.

1. Was ist eine Pull-Request-Überprüfung?

Eine Pull-Request-Überprüfung (Code Review) ist der Prozess, bei dem eine oder mehrere Personen den Code eines PR analysieren, bevor er in den Haupt-Branch eines Projekts gemergt wird. Ziel der Überprüfung ist es, sicherzustellen, dass der Code fehlerfrei, verständlich, konsistent und gut dokumentiert ist.

2. Gründe für eine Pull-Request-Überprüfung

  • Fehlererkennung: Durch das Review können Fehler oder logische Schwächen im Code entdeckt werden, bevor sie in das Hauptprojekt gelangen.
  • Codequalität verbessern: Der Reviewer stellt sicher, dass der Code den besten Praktiken folgt und gut strukturiert ist.
  • Lernmöglichkeiten: Für das Team ist es eine Gelegenheit, voneinander zu lernen und die eigenen Programmierfähigkeiten zu verbessern.
  • Konsistenz gewährleisten: Sicherstellen, dass der Code den Richtlinien und Standards des Projekts entspricht.

3. Best Practices für Pull-Request-Überprüfungen

1. Verstehen, was der Pull Request tut

Bevor mit der Überprüfung des Codes begonnen wird, sollte der Kontext des PR verstanden werden: - Was versucht der Pull Request zu ändern oder zu verbessern? - Welche Problemstellung löst er? - Wurden in der Beschreibung des PR klare Ziele und Anweisungen angegeben?

Lesen der Beschreibung, das Nachvollziehen der Änderungen und Verstehen des zugrunde liegenden Problems sind unerlässlich, um fundiertes Feedback zu geben.

2. Überprüfe kleine Pull Requests

Kleine Pull Requests sind einfacher zu überprüfen und reduzieren die Wahrscheinlichkeit, dass Fehler übersehen werden. Eine PR sollte idealerweise nicht mehr als 200 bis 300 Zeilen Änderungen umfassen, da größere Änderungen schwieriger zu verstehen sind.

Tipp für Entwickler:

Falls ein PR zu groß wird, erwäge, ihn in mehrere kleinere PRs aufzuteilen.

3. Schrittweise Überprüfung

  • Datei für Datei: Beginne mit der Überprüfung einzelner Dateien. Prüfe die Struktur, die Namenskonventionen und ob jede Datei die beabsichtigte Funktionalität korrekt implementiert.
  • Logik und Funktionalität: Prüfe, ob der Code das tut, was er laut Beschreibung tun soll.
  • Fehler und Ausnahmen: Achte auf potenzielle Fehler, Randfälle oder unbehandelte Ausnahmen.

4. Prüfe auf Konsistenz

Konsistenz ist in einem Projekt sehr wichtig. Achte darauf, dass der PR: - den Coding Guidelines des Projekts folgt (z. B. Namenskonventionen, Formatierung). - eine ähnliche Struktur wie der vorhandene Code hat. - die bestehenden Funktionen und Datenstrukturen korrekt verwendet, anstatt neue unnötige zu erstellen.

5. Code-Lesbarkeit und Wartbarkeit

Der Code sollte leicht verständlich und gut dokumentiert sein. Prüfe, ob: - die Namen von Variablen und Funktionen klar und beschreibend sind. - der Code in logische Abschnitte unterteilt ist. - Kommentare verwendet werden, um komplexe oder nicht sofort verständliche Abschnitte zu erklären.

Ein guter Indikator für wartbaren Code ist, ob du den Code ohne lange nachdenken zu müssen verstehst.

6. Testabdeckung sicherstellen

Eine wichtige Praxis ist, sicherzustellen, dass der PR ausreichend getestet wird. Hierbei sollten: - Unit-Tests: Jede Funktion sollte eigene Tests haben, die sicherstellen, dass sie wie erwartet funktioniert. - Integrationstests: Wenn der PR mehrere Teile des Codes verändert, sollten Integrationstests sicherstellen, dass die verschiedenen Komponenten korrekt zusammenarbeiten. - Randfälle: Prüfe, ob Randfälle getestet werden, insbesondere bei Grenzwerten, ungültigen Eingaben oder Ausnahmen.

Überprüfe, ob der PR selbst Tests enthält, und prüfe, ob die Tests alle wichtigen Szenarien abdecken.

7. Automatische Tests und CI prüfen

In vielen Projekten wird Continuous Integration (CI) verwendet, um Pull Requests automatisch zu testen. Es ist wichtig, dass der PR die automatischen Tests besteht, bevor er gemergt wird. Stelle sicher, dass alle Tests in der CI-Pipeline bestanden werden und es keine Fehler gibt.

Wenn ein Test fehlschlägt: - Schau dir die Fehlermeldungen an. - Verlange, dass der Entwickler den Fehler behebt, bevor der PR gemergt wird.

8. Gib konstruktives Feedback

Das Ziel eines Pull-Request-Reviews ist es, den Code zu verbessern und den Entwickler zu unterstützen. Das Feedback sollte immer konstruktiv und hilfreich sein. Anstatt nur auf Fehler hinzuweisen, sollte der Reviewer erklären: - Warum ein bestimmter Abschnitt problematisch ist. - Vorschläge für Verbesserungen machen. - Positive Aspekte des PR hervorheben, um den Entwickler zu motivieren.

Beispiel für konstruktives Feedback:

  • Negativ: "Das ist schlecht."
  • Konstruktiv: "Dieser Teil des Codes ist schwer verständlich. Vielleicht kannst du ihn in eine Funktion aufteilen und die Variablen besser benennen?"

9. Hinterfrage Annahmen

Manchmal werden Annahmen im Code getroffen, die zu zukünftigen Fehlern führen könnten. Frage dich: - Gibt es Annahmen über Eingaben oder Randfälle, die zu Fehlern führen könnten? - Wurden mögliche Ausnahmen oder ungültige Eingaben bedacht?

Durch das Hinterfragen dieser Annahmen können potenzielle Probleme frühzeitig erkannt werden.

10. Zusammenführung von Pull Requests

Wenn der PR die Überprüfung besteht und alle Kommentare geklärt wurden, kann der PR gemergt werden. Prüfe jedoch vor dem Merge: - Konflikte: Gibt es Konflikte zwischen dem PR und dem Ziel-Branch? Diese müssen gelöst werden, bevor ein Merge möglich ist. - Teststatus: Vergewissere dich, dass alle Tests bestanden wurden.

Je nach Projekt kann der Reviewer den PR selbst mergen oder dem Autor überlassen, nachdem das Review abgeschlossen ist.


4. Typische Fehler bei Pull-Request-Überprüfungen

  1. Zu oberflächlich: Den Code nicht tief genug überprüfen, sodass Probleme übersehen werden.
  2. Zu kleinlich: Sich auf unwichtige Details wie Formatierungsfehler zu konzentrieren, anstatt sich auf die Funktionalität und Struktur zu konzentrieren.
  3. Fehlende Kommunikation: Feedback geben, ohne dem Autor zu erklären, warum bestimmte Änderungen notwendig sind.
  4. Nicht genug Tests: Keine Überprüfung, ob der Code ausreichend getestet wurde.

5. Zusammenfassung

Die Überprüfung von Pull Requests ist ein wichtiger Prozess, der dazu beiträgt, die Qualität und Stabilität eines Projekts sicherzustellen. Indem du den PR sorgfältig überprüfst, konstruktives Feedback gibst und sicherstellst, dass der Code getestet ist, kannst du dazu beitragen, dass nur gut strukturierter und funktionierender Code in den Haupt-Branch gelangt.

Best Practices zusammengefasst: - Verstehe den Zweck des PR. - Achte auf kleine, überschaubare Pull Requests. - Prüfe auf Konsistenz, Lesbarkeit und Testabdeckung. - Gib konstruktives und hilfreiches Feedback. - Sicherstelle, dass alle automatischen Tests bestehen.

Mit diesen Best Practices kannst du den Code-Review-Prozess effizienter gestalten und gleichzeitig die Codequalität deines Projekts verbessern.