Code-Review: Arten, Organisation und bewährte Verfahren

· Imen Ezzine · 3 Minuten zum Lesen
Code happy in lights

Der Code-Review ist ein wesentlicher Schritt im Softwareentwicklungszyklus, der es ermöglicht, die Qualität des Codes zu verbessern, Fehler zu reduzieren und den Wissensaustausch innerhalb des Teams zu fördern. GitLab und GitHub, zwei der beliebtesten Plattformen für die Codeverwaltung, bieten erweiterte Funktionen, um diesen Prozess zu vereinfachen. Dieser Artikel befasst sich mit den verschiedenen Arten von Code-Reviews, der Organisation und der Nutzung von Vorlagen und Checklisten zur Verbesserung der Effizienz von PRs (Pull Requests).

1. Arten von Code-Review

Es gibt verschiedene Arten von Code-Reviews, die jeweils spezifische Ziele verfolgen. Hier sind die wichtigsten:

a. Der Ad-hoc-Code-Review

Dieser Review ist informell und wird oft bei kleinen Änderungen durchgeführt. Der Entwickler kann einen oder zwei Kollegen bitten, einen Blick auf seinen Code zu werfen, ohne dass dabei strenge Verfahren einzuhalten sind. Diese Art des Reviews ist schnell, kann jedoch an Genauigkeit einbüßen, wenn die Korrekturleser nicht aufmerksam genug sind.

b. Code-Review im Pull-Request-Modus (PR)

Dies ist die gängigste Methode bei GitHub und GitLab. Ein PR wird eingereicht, wenn eine neue Funktion, eine Fehlerbehebung oder eine Verbesserung fertig ist. Ein oder mehrere Entwickler prüfen den PR, bevor er in den Haupt-Branch integriert wird.

c. Der synchrone Code-Review

Es handelt sich um einen Review in Echtzeit, die häufig mithilfe von Peer-Programming-Tools oder Bildschirmfreigabe-Tools durchgeführt wird. Dieser Ansatz ist für kritische oder dringende Projekte nützlich, erfordert jedoch die gleichzeitige Verfügbarkeit beider Parteien.

d. Automatisierte Codeüberprüfung

Mit Hilfe von Tools wie SonarQube oder den CI/CD-Pipelines von GitLab werden bestimmte Reviews (Tests, Linting, Sicherheitsanalysen) automatisiert, um grundlegende Probleme zu erkennen, noch bevor ein menschlicher Review stattfindet.

Darüber hinaus bieten Lösungen mit KI (wie GitHub Copilot, CodeRabbit oder AI Code Review Action) nun die Möglichkeit, Code-Reviews teilweise zu automatisieren. Diese Lösungen können zwar die Identifizierung von Fehlern oder schlechten Praktiken beschleunigen, ihre Empfehlungen sollten jedoch mit Vorsicht interpretiert werden: Sie ersetzen nicht das Fachwissen eines erfahrenen Entwicklers. Schließlich sollte auch die Frage der Datenhoheit im Auge behalten werden. Die Inanspruchnahme externer Dienste kann zur Offenlegung des Codes führen und Fragen der Vertraulichkeit oder der Einhaltung gesetzlicher Vorschriften aufwerfen.

2. Organisation eines Code-Reviews

Für einen effektiven Code-Review ist eine strenge Organisation von entscheidender Bedeutung. Hier sind einige Tipps zur Strukturierung dieses Prozesses auf GitLab und GitHub:

a. Stell einen klaren Prozess auf

Jedes Team sollte klare Regeln dafür haben, wann ein PR zum Code-Review bereit ist, wer ihn überprüfen muss und wie viele Genehmigungen vor dem Merge erforderlich sind. Eine Regel könnte beispielsweise lauten: „Jeder PR muss von mindestens zwei Teammitgliedern reviewed und durch automatische Tests validiert werden.“

.b. PRs aufsplitten

Zu umfangreiche PRs können schwierig zu reviewen sein. Es wird empfohlen, Funktionen oder Korrekturen in überschaubare Teile aufzusplitten, die jeweils mit einem separaten PR verknüpft sind. Dadurch können sich die Reviewer auf bestimmte Änderungen konzentrieren und qualitativ hochwertigeres Feedback geben.

c. PRs auf notwendige Änderungen beschränken

Nur Änderungen, die in direktem Zusammenhang mit einer Aufgabe oder einem Ticket stehen, sollten in einem PR enthalten sein. Das mischen von Refactorings oder anderen Verbesserungen kann den Code-Review erschweren und das Verständnis der Absichten hinter den Änderungen erschweren.

3. Verwendung von Templates für Pull-Requests

GitLab und GitHub ermöglichen die Verwendung von Templates, um Pull-Requests zu standardisieren und den Überprüfungsprozess methodischer zu gestalten. So richten Sie diese ein.

a. Erstellen eines Pull-Request-Templates auf GitHub

Erstelle zunächst eine Datei namens PULL_REQUEST_TEMPLATE.md im .github/ Verzeichnis deines Repositorys.

Diese Datei kann vordefinierte Abschnitte enthalten, wie zum Beispiel:

## Beschreibung
Bitte geben Sie eine kurze Beschreibung der Änderungen an.

## Art der Änderung
- [ ] Fehlerbehebung 
- [ ] Neue Funktion 
- [ ] Refaktorisierung 

## Tests
- [ ] Sind Unit-Tests vorhanden? 
- [ ] Ist die Dokumentation aktualisiert?

b. Erstellen eines Pull-Request-Templates auf GitLab

1. In GitLab werden PR-Templates im .gitlab/merge_request_templates/ Verzeichnis abgelegt.

2. Wie bei GitHub können Sie hier eine nützliche Struktur einfügen, um den Entwicklern eine Orientierungshilfe zu geben:

## Ziel dieser PR
Fassen Sie die Änderungen und deren Zweck zusammen.

## Verwandte Links
– JIRA- oder GitLab-Ticket: [Link]

## Überprüfungen
– [ ] Sind alle Tests erfolgreich durchgelaufen?
– [ ] Wurde der Code reviewed?

Diese Templates stellen sicher, dass die PRs alle Informationen enthalten, die für einen vollständige Code-Review erforderlich sind.

4. Erstellen Sie eine Checkliste

Eine Checkliste ist eine hervorragende Möglichkeit, um sicherzustellen, dass vor dem Merge jeder Aspekt des Codes berücksichtigt wurde. Hier ist ein Beispiel für eine Checkliste, die in PR-Templates aufgenommen werden kann:

Beispiele für Punkte, die in einer Checkliste überprüft werden sollten:

  • Der Code entspricht den Stilkonventionen des Teams.

  • Alle neuen Dateien enthalten die richtigen Lizenz-Header.

  • Neue Funktionen werden durch geeignete Tests abgedeckt (je nach Fall Unit- oder Functionaltests).

  • Der Code wurde in Entwicklungs- und simulierten Produktionsumgebungen getestet.

  • Es wurden keine veralteten, nicht mehr gepflegten oder aufgegebenen Abhängigkeiten eingeführt.

  • Es wurde keine veraltete Syntax oder APIs verwendet.

  • Die technische Dokumentation wurde bei Bedarf aktualisiert.

  • Die Auswirkungen der Änderungen auf die Performance wurde überprüft.

5. Automatisiere bestimmte Schritte mit GitLab CI/CD oder GitHub Actions

GitLab und Github ermöglichen die Integration von CI/CD-Pipelines, um bestimmte Schritte der PR-Validierung zu automatisieren. So können Tests, Codequalitätsprüfungen oder Sicherheitsanalysen durchgeführt werden, bevor die manuelle Überprüfung beginnt. Sie können beispielsweise eine Pipeline konfigurieren, um:

Unit- und Functionaltests durchzuführen.

Linting-Tools zu starten, um Konventionen zu überprüfen.

Tools wie SonarQube zu verwenden, um Schwachstellen oder Code Smells zu erkennen.

Fazit

Der Code-Review ist eine wichtige Maßnahme, um die Qualität des Codes sicherzustellen. GitHub und GitLab bieten Tools und Funktionen, mit denen sich dieser Prozess bei richtiger Anwendung effizient und konsequent organisieren lässt. Durch die Verwendung von Pull-Request-Templates, die Erstellung von Checklisten und die Automatisierung bestimmter Schritte mithilfe von CI/CD-Pipelines kann dein Team seine Produktivität steigern, Fehler reduzieren und einen Wissensaustausch fördern, von dem alle profitieren.

Für einen erfolgreichen Code-Review sind Organisation und Kommunikation entscheidend. Die Anwendung bewährter Verfahren auf diesen Plattformen trägt zu robusteren Entwicklungsprozessen und einer besseren Codequalität bei.

Willst du die Qualität deiner Code-Reviews verbessern und die Arbeitsabläufe deines Teams strukturieren?

Unser Team hilft Dir, deinen Code besser zu machen. Dazu gehört auch, den Code zu reviewen. Wir helfen Dir gerne dabei, einen guten Prozess für gemeinsame Code-Reviews zu entwickeln.

Image