Przez długi czas podchodziłem do CR trochę po macoszemu. Przeglądałem tylko zmiany w narzędziu do zarządzania kodem. Nie interesowało mnie jak to faktycznie działa. Z perspektywy czasu widzę, że mój CR mógł być lepszy gdybym analizował kod również lokalnie.
Podam Ci 4 powody, dla których warto pobrać brancha lokalnie i jak taka analiza uczyni CR łatwiejszym 🙂
1. Łatwiej przeanalizujesz kod, gdy IDE podświetli Ci składnię
Jeśli korzystasz z Gitlaba wiesz że często źle podświetla on składnię języka. Inne narzędzia do CR też nie zawsze dają radę.
Twórcy narzędzi ciągle je udoskonalają i sytuacja ta ulegnie poprawie. Nadal jednak pozostają indywidualne ustawienia IDE danego programisty.
Wśród użytkowników Intellij IDEA popularny motyw to Material Theme.
Wielu programistów używa też customowych czcionek, chociażby po to by operator “różny od” czyli !== zamienić na przekreślony znak równości.
Więc efektywniej przejrzysz zmiany po pobraniu ich lokalnie. Zobaczysz je jako “swoje” dzięki temu, że będą osadzone w Twoim ekosystemie.
2. Odtworzysz błędy które ktoś zgłosił
Nawet mając rozbudowane testy, warto klikać wprowadzane zmiany. Szczególnie gdy w zespole są mniej doświadczone z systemem osoby. Mogą one nie wiedzieć o wszystkich ścieżkach jakimi może pójść aplikacja.
Uruchomienie aplikacji lokalnie pozwoli zbadać wpływ tych zmian na obecne funkcjonalności. A także czy faktycznie problem znika gdy kod zawiera zmiany z brancha.
Ludzie robiący CR lokalnie mają okazję też określić nowe przypadki testowe. Autor będzie mógł więc uzupełnić testy automatyczne.
3. Sprawdzisz potencjalne sugestie i pytania bezpośrednio w kodzie
Zdarzyło mi się kilkukrotnie zapytać o coś, co byłoby jasne gdybym sprawdził zmiany lokalnie w IDE.
Bądź chociaż otworzył cały plik zamiast widzieć tylko samą zmianę bez kontekstu.
Przykładowo – zobaczyłem użycie key i zwróciłem uwagę, że ma on sens tylko wtedy, gdy mamy pętlę.
Jak się okazało pętla tam była 🙂 Znajdowała się jednak tak daleko od miejsca zmiany w kodzie, że Gitlab ukrył zawierający ją kod.
Rozwiązania na takie przypadki są dwa. Zobaczyć zmiany w kontekście całego pliku albo zobaczyć zmiany lokalnie.
O zmianie kontekstu na pełny plik możemy zapomnieć, a przeglądając lokalnie mamy to w standardzie.
4. Zdebugujesz kod
Wreszcie – jedna z istotniejszych rzeczy, w programowaniu. Debugowanie 🙂 Mając kod lokalnie będziesz w stanie go zdebugować. Pozwoli Ci to na dokładniejsze poznanie zasad działania wprowadzanych zmian. Łatwiej znajdziesz też możliwe anomalie.
Podsumowanie
Dobra rada – zacznij analizować kod lokalnie 🙂 Przyłożenie się do CR opłaci się całej Twojej organizacji. Zaoszczędzisz czas na pytaniach. Dasz bardziej wartościowy feedback. Odkryjesz nowe ścieżki którymi może pójść aplikacja. A także, łatwiej wczujesz się w perspektywę osoby która ten kod pisała.
