Wie wurde der Code-Review-Prozess in Ihrem Team…

Wir haben die gemeinsame Entwicklung mit Hilfe des Versionskontrollsystems Git und Plattformen zur Repository-Verwaltung (z.B. Bitbucket oder GitLab) genutzt. Der Code-Review-Prozess wurde wie folgt organisiert:

Branch-Erstellung: Der Entwickler erstellt einen separaten Branch für eine neue Funktion oder Fehlerbehebung (git checkout -b feature/my-new-feature).
Entwicklung und Commits: Änderungen werden im Branch vorgenommen und durch Commits festgehalten (git add ., git commit -m "Initiale Funktionsimplementierung").
Push zum Remote-Repository: Der Branch wird ins Remote-Repository gepusht (git push origin feature/my-new-feature).
Erstellung eines Pull/Merge Requests: Der Entwickler erstellt einen Pull Request (bei Bitbucket) oder Merge Request (bei GitLab), wobei der Ziel-Branch angegeben wird (z.B. develop oder main). In der Beschreibung werden die Änderungen, Links zu den Aufgaben im Tracker (Jira, Trello usw.) und angehängte Dateien (Screenshots, Videos, Diagramme) aufgeführt.
Zuweisung von Reviewern: Ein oder zwei Entwickler aus dem Team werden für die Review zugewiesen.

Review-Prozess: Die Reviewer prüfen die Änderungen im Pull/Merge Request. Sie können Kommentare hinterlassen, Verbesserungen vorschlagen, Fragen stellen.

// Beispiel für einen Kommentar während der Review
function fetchData() {
  // Hier sollte eventuell Fehlerbehandlung bei der Datenanfrage hinzugefügt werden
  return fetch('/api/data');
}

Änderungen nach der Review: Der Entwickler nimmt die notwendigen Änderungen basierend auf den Kommentaren der Reviewer vor und macht neue Commits.
Aktualisierung des Pull/Merge Requests: Die Änderungen werden automatisch im Pull/Merge Request angezeigt, nachdem sie ins Remote-Repository gepusht wurden.
Wiederholte Review: Die Reviewer prüfen die Änderungen erneut und geben ihre Zustimmung.
Merge des Branches: Nach Erhalt der Zustimmung wird der Branch in den Ziel-Branch gemerged (meist automatisiert durch die Plattform nach Bestehen des CI/CD-Pipelines).

Wir haben auch CI/CD-Pipelines verwendet, um automatisch Unit-Tests, statische Code-Analysen (ESLint, Prettier) und den Build des Projekts vor dem Merge durchzuführen, was half, Fehler frühzeitig zu erkennen.

Kriterien für eine erfolgreiche Review waren:

Erfüllung der Aufgabenanforderungen.
Einhaltung des Code-Stils des Teams.
Vorhandensein von Unit-Tests für kritische Logik.
Keine offensichtlichen Fehler und "Konstrukte".
Verständlichkeit des Codes für andere Teammitglieder.

Wie wurde der Code-Review-Prozess in Ihrem Team organisiert?