Proces przeglądu kodu (code review) stanowi fundament dbałości o jakość oprogramowania, lecz przy współpracy z zewnętrznymi dostawcami IT może łatwo przekształcić się w poważne wąskie gardło operacyjne. Wczesne zdefiniowanie reguł akceptacji, standardów technicznych oraz rytmu pracy pozwala uniknąć sytuacji, w której zadania utkną w martwym punkcie jeszcze przed zatwierdzeniem pierwszych zmian.
Dlaczego code review może stać się bottleneckiem?
Code review ma chronić jakość kodu. Przy współpracy z zewnętrznym zespołem może jednak szybko stać się bottleneckiem. Nie dlatego, że review jest zbędne. Wręcz przeciwnie. Gdy nad jednym systemem pracują osoby z różnych zespołów, wspólne standardy są jeszcze ważniejsze. Problem zaczyna się wtedy, gdy zasady review nie są ustalone przed startem współpracy.
Zewnętrzny zespół dostarcza pull requesty. Wewnętrzny zespół nie ma czasu ich sprawdzać. Komentarze pojawiają się po kilku dniach. Część decyzji architektonicznych wraca do dyskusji. Zadania formalnie są „w review”, ale realnie nie przesuwają backlogu. Wtedy dodatkowa capacity nie przyspiesza delivery. Tworzy kolejkę do akceptacji.
Jak ustalić ownership review?
Pierwsza rzecz do ustalenia to ownership review.
- Kto sprawdza kod?
- Czy każdy pull request wymaga akceptacji tech leada klienta?
- Czy zewnętrzny zespół wykonuje własne review przed przekazaniem zmian?
- Czy są obszary systemu, które wymagają dodatkowej kontroli?
- Czy reviewer ma oceniać tylko zgodność z wymaganiami, czy również decyzje architektoniczne?
Bez tych odpowiedzi review zaczyna działać przypadkowo. Jedne zmiany przechodzą szybko, inne blokują się bez jasnego powodu. Zewnętrzny zespół nie wie, czy problemem jest jakość kodu, brak kontekstu, styl pracy czy po prostu brak dostępności osoby po stronie klienta.
Jak opisać standard kodu przed startem?
Druga rzecz to standard kodu. Jeżeli standardy istnieją tylko w głowach kilku osób, zewnętrzny zespół będzie poznawał je przez odrzucane pull requesty. To kosztowny sposób onboardingu. Przed rozpoczęciem pracy warto opisać przynajmniej podstawowe zasady:
- strukturę projektu,
- konwencje nazewnictwa,
- podejście do testów,
- zasady obsługi błędów,
- wymagania bezpieczeństwa,
- branching strategy,
- format pull requesta,
- definition of done.
Nie chodzi o tworzenie dokumentacji dla samej dokumentacji. Chodzi o to, żeby review nie było miejscem przekazywania wszystkich niepisanych zasad projektu.
Dlaczego warto zmniejszać rozmiar pull requestów?
Trzecia rzecz to rozmiar zmian. Duże pull requesty są trudniejsze do sprawdzenia, bardziej ryzykowne i częściej blokują się na review. Przy pracy z zewnętrznym zespołem warto szczególnie pilnować, żeby zmiany były mniejsze, lepiej opisane i łatwiejsze do oceny. Mniejszy pull request szybciej przechodzi przez review. Szybsze review oznacza krótszy feedback loop. Krótszy feedback loop oznacza mniej pracy poprawkowej i mniejsze ryzyko, że zespół pójdzie kilka kroków w złym kierunku.
Jak przyspieszyć review dzięki kontekstowi i rytmowi pracy?
Czwarta rzecz to kontekst biznesowy i techniczny. Reviewer nie powinien zgadywać, dlaczego dana zmiana została wykonana. Dobry pull request powinien zawierać krótki opis problemu, zakres zmiany, wpływ na inne części systemu, sposób testowania i ewentualne ryzyka. To szczególnie ważne w aplikacjach legacy, gdzie pojedyncza zmiana może dotykać zależności niewidocznych na pierwszy rzut oka. Jeżeli zewnętrzny zespół nie opisuje kontekstu, review trwa dłużej. Jeżeli wewnętrzny zespół nie przekazuje kontekstu wcześniej, implementacja może wymagać poprawek, których dało się uniknąć.
Piąta rzecz to czas reakcji. Code review nie powinno być zadaniem wykonywanym „kiedy ktoś znajdzie chwilę”. Jeżeli zewnętrzny zespół ma dowozić określony zakres, review musi mieć przewidywalny rytm. Warto ustalić:
- kto reviewuje,
- w jakim czasie,
- co zrobić, gdy reviewer jest niedostępny,
- kiedy eskalować blokadę,
- które zmiany wymagają synchronizacji technicznej przed implementacją.
Bez tego pull requesty mogą stać się ukrytą kolejką, której nikt formalnie nie planuje, ale wszyscy odczuwają jej skutki.
Jak automatyzacja wspiera code review?
Szósta rzecz to automatyzacja. Nie wszystko powinno trafiać do ręcznego review. Część kontroli można przenieść do pipeline’u: formatowanie, statyczna analiza kodu, testy jednostkowe, testy integracyjne, skanowanie zależności, podstawowe reguły jakości.
Im więcej powtarzalnych kontroli wykonuje system, tym bardziej reviewer może skupić się na decyzjach, których nie da się łatwo zautomatyzować: architekturze, czytelności, ryzyku, zgodności ze sposobem działania aplikacji.
Jak Prognetics traktuje code review w delivery?
W Prognetics traktujemy code review jako element delivery, a nie osobny etap na końcu pracy. Jeżeli dołączamy do zespołu klienta, dopasowujemy się do jego standardów review i procesu akceptacji. Jeżeli przejmujemy określony zakres, ustalamy, jak wygląda review wewnętrzne, kiedy potrzebna jest akceptacja klienta i co musi być spełnione przed release’em.
Celem nie jest ominięcie kontroli jakości. Celem jest taki model review, który utrzymuje standardy bez zatrzymywania delivery. Code review działa dobrze, gdy jest przewidywalne, konkretne i oparte na jasnych zasadach. Działa źle, gdy staje się miejscem nadrabiania brakującego onboardingu, niejasnego ownershipu i opóźnionych decyzji.
Od czego zacząć rozmowę o review i release?
Przed rozpoczęciem pracy z zewnętrznym zespołem warto ustalić, jak zmiany będą przechodziły od pull requesta do release’u. W praktyce trzeba określić:
- kto reviewuje kod,
- jak szybko powinien pojawić się feedback,
- które obszary systemu wymagają dodatkowej akceptacji,
- co musi znaleźć się w pull requeście,
- jakie testy i quality checks są wymagane przed merge’em,
- kto decyduje, że zmiana jest gotowa do wdrożenia.
Dzięki temu code review nie staje się miejscem nadrabiania brakującego onboardingu. Zespół zewnętrzny zna zasady pracy od początku, a zespół klienta nie musi tłumaczyć tych samych oczekiwań przy każdym pull requeście. Review powinno chronić jakość kodu, nie tworzyć kolejną kolejkę do akceptacji.
