Jak zorganizowano procedurę przeglądu kodu w Twoim zespole?

Używaliśmy wspólnego rozwoju za pomocą systemu kontroli wersji Git i platform do zarządzania repozytoriami (np. Bitbucket lub GitLab). Proces przeglądu kodu został zorganizowany w następujący sposób:

1. Tworzenie gałęzi: Programista tworzy osobną gałąź dla nowej funkcji lub poprawki błędu (git checkout -b feature/my-new-feature).
2. Rozwój i commity: W gałęzi dokonywane są zmiany, które są rejestrowane przez commity (git add ., git commit -m "Wstępna implementacja funkcji").
3. Push do zdalnego repozytorium: Gałąź jest wysyłana do zdalnego repozytorium (git push origin feature/my-new-feature).
4. Tworzenie Pull/Merge Request: Programista tworzy Pull Request (w Bitbucket) lub Merge Request (w GitLab), wskazując docelową gałąź (np. develop lub main). W opisie podaje się krótkie podsumowanie zmian, linki do zadań w trackerze (Jira, Trello itp.) oraz załączniki (zrzuty ekranu, filmy, diagramy).
5. Przypisanie reviewerów: Do przeprowadzenia przeglądu przypisuje się jednego lub dwóch programistów z zespołu.
6. Proces przeglądu: Reviewerzy przeglądają zmiany w Pull/Merge Request. Mogą zostawiać komentarze, proponować ulepszenia, zadawać pytania.

   // Przykład komentarza podczas przeglądu
   function fetchData() {
     // Może tutaj warto dodać obsługę błędów przy żądaniu danych
     return fetch('/api/data');
   }
   

7. Wprowadzanie zmian po przeglądzie: Programista wprowadza niezbędne zmiany na podstawie komentarzy reviewerów i tworzy nowe commity.
8. Aktualizacja Pull/Merge Request: Zmiany automatycznie pojawiają się w Pull/Merge Request po pushu do zdalnego repozytorium.
9. Powtórny przegląd: Reviewerzy ponownie przeglądają zmiany i zatwierdzają je.
10. Scalenie gałęzi: Po uzyskaniu zatwierdzenia gałąź jest scalana z gałęzią docelową (zazwyczaj automatycznie przez platformę po przejściu przez pipeline CI/CD).

Używamy również pipeline'ów CI/CD do automatycznego uruchamiania testów jednostkowych, analizy statycznej kodu (ESLint, Prettier) i budowania projektu przed scaleniem, co pomagało wykrywać błędy na wczesnym etapie.

Kryteria pomyślnego przejścia przeglądu obejmowały:

• Zgodność z wymaganiami zadania.
• Przestrzeganie stylu kodowania zespołu.
• Obecność testów jednostkowych dla krytycznej logiki.
• Brak oczywistych błędów i "obejść".
• Czytelność kodu dla innych członków zespołu.