Przeglądy kodu i zatwierdzenia

Przeglądy kodu są jednym z fundamentów współczesnego tworzenia oprogramowania. Polegają na systematycznej analizie kodu źródłowego przez współpracowników w celu znalezienia i naprawienia błędów przeoczonych na początkowym etapie pracy.

Do najważniejszych celów należą:

• Poprawa jakości kodu: Wczesne wykrywanie błędów, luk w zabezpieczeniach i wad projektowych.
• Dzielenie się wiedzą: Rozpowszechnianie wiedzy o bazie kodu w całym zespole.
• Mentoring: Starsi stażem programiści mogą wspierać młodszych, a wszyscy uczą się dzięki różnym perspektywom.

W GitHub proces przeglądu kodu zazwyczaj przebiega następująco:

1. Autor tworzy Pull Request (PR) zawierający zmiany.
2. Autor przypisuje recenzentów lub wysyła prośby o recenzję.
3. Recenzenci analizują kod, dodając komentarze i sugestie.
4. Autor uwzględnia uwagi, wypychając nowe zatwierdzenia do gałęzi PR.
5. Gdy recenzenci są zadowoleni, zatwierdzają zmiany.
6. Na końcu PR zostaje scalony z główną gałęzią.

Dobry przegląd kodu nie polega wyłącznie na znajdowaniu błędów, lecz także na poprawie ogólnego stanu projektu. Podczas przeglądu należy uwzględnić:

• Poprawność: Czy kod robi to, co powinien? Czy uwzględnia przypadki brzegowe?
• Czytelność: Czy łatwo go zrozumieć? Czy nazwy zmiennych są jasne?
• Łatwość utrzymania: Czy inni będą mogli łatwo później modyfikować lub rozszerzać ten kod?
• Wydajność: Czy występują oczywiste nieefektywności?
• Bezpieczeństwo: Czy kod wprowadza jakieś luki w zabezpieczeniach?

Jako recenzent zawsze przekazuj konstruktywne i pełne szacunku uwagi. Pamiętaj, że oceniasz kod, a nie osobę, która go napisała.

Wskazówki dotyczące przekazywania opinii:

• Bądź konkretny: Wskazuj dokładne wiersze kodu.
• Wyjaśnij „dlaczego”: Nie mów tylko „zmień to” — wyjaśnij, *dlaczego* należy to zmienić.
• Proponuj rozwiązania: Oferuj alternatywne podejścia lub fragmenty kodu.
• Bądź uprzejmy: Używaj grzecznego języka i zakładaj dobre intencje.

GitHub udostępnia zaawansowane narzędzia usprawniające proces przeglądu:

• Komentarze do wierszy: Kliknij wiersz na karcie „Files changed”, aby bezpośrednio dodać komentarz.
• Suggestions: Możesz zaproponować konkretne zmiany w kodzie, które autor zastosuje jednym kliknięciem.
• Przegląd podsumowujący: Na końcu możesz przesłać podsumowanie przeglądu ze statusem „Comment”, „Approve” lub „Request changes”.

Suggestions są szczególnie przydatne w przypadku niewielkich, jasnych usprawnień:

// Original Code
- const count = 0;
+ const initialCount = 0; // Better name

Jeśli są Państwo autorem Pull Requestu, odpowiadanie na uwagi ma kluczowe znaczenie. Pokazuje zaangażowanie i gotowość do ulepszania kodu.

Podczas uwzględniania komentarzy:

• Potwierdź otrzymanie: Odpowiedz na każdy komentarz, nawet jeśli tylko po to, by napisać „Dobra uwaga!” lub „Gotowe”.
• Wprowadź zmiany: Wypchnij nowe zatwierdzenia do gałęzi PR. GitHub automatycznie zaktualizuje PR.
• Rozwiąż dyskusje: Po uwzględnieniu komentarza oznacz go w GitHub jako „Resolved”.
• Zadawaj pytania: Jeśli nie rozumiesz sugestii, poproś o wyjaśnienie.

Status „Approve” to jasny sygnał, że recenzent jest zadowolony ze zmian w Pull Requeście. Wiele repozytoriów jest skonfigurowanych tak, aby przed scaleniem PR wymagać co najmniej jednego (lub większej liczby) zatwierdzeń.

Zatwierdzenie oznacza, że zdaniem recenzenta kod:

• Spełnia wymagania.
• Jest dobrze napisany i łatwy w utrzymaniu.
• Uwzględnia wszystkie istotne zastrzeżenia.

To zielone światło dla integracji!

Czasami Pull Request wymaga dalszych prac, zanim będzie można go scalić. W takiej sytuacji recenzent może wybrać status „Request changes”.

Ten status jasno komunikuje, że:

• Występują blokujące problemy, które należy rozwiązać.
• PR nie może zostać scalony, dopóki te zmiany nie zostaną wprowadzone i recenzent nie udzieli nowego zatwierdzenia.

Użyj tej opcji, gdy problemy są istotne i uniemożliwiają zaakceptowanie kodu.

Aby jak najlepiej wykorzystać przeglądy kodu, zarówno autorzy, jak i recenzenci powinni stosować kilka dobrych praktyk:

• Twórz małe PR-y: Mniejsze PR-y łatwiej i szybciej się przegląda.
• Jasne opisy: Autorzy powinni dostarczać szczegółowe opisy PR-ów i kontekst zmian.
• Reaguj szybko: Recenzenci powinni starać się szybko przeprowadzać przeglądy, a autorzy szybko odpowiadać.
• Automatyzuj to, co się da: Korzystaj z linterów i automatycznych testów, aby wykrywać proste problemy jeszcze przed przeglądem.
• Ucz się z przeglądów: Traktuj każdy przegląd jako okazję do nauki i doskonalenia.

Biorąc pod uwagę to, czego się nauczyliśmy, które z poniższych działań uznaje się za dobre praktyki udziału w przeglądach kodu?

Poznali Państwo świat przeglądów kodu i funkcji zatwierdzania w GitHub! Omówiliśmy znaczenie przeglądów dla jakości kodu i dzielenia się wiedzą, typowy przebieg przeglądu oraz najważniejsze elementy dobrych praktyk.

Pamiętaj, aby zawsze przekazywać konstruktywne uwagi, korzystać z narzędzi GitHub, takich jak suggestions, oraz stosować dobre praktyki zarówno podczas przeglądania kodu, jak i odpowiadania na uwagi. Statusy „Approve” i „Request changes” to kluczowe sygnały pomagające skutecznie zarządzać PR-ami.

Ćwicz te umiejętności, aby stać się wartościowym współpracownikiem!