Pull request zagościł na dobre w większości projektów. Bez względu na to, czy chcemy wykorzystać go do code review, czy do bezpiecznego wchodzenia na produkcję, stał się narzędziem, które ciężko zastąpić. Czy to jednak nie spowodowało, iż trochę go nadużywamy? Osobiście mam dobre doświadczenia z PR’ami, ale znam wiele osób, które chętnie pozbyły by się ze swojego procesu. Tylko co wprowadzić w zamian?
Ostatnio na Clubhouse zorganizowałam dyskusję na temat pull requestów i muszę przyznać, iż doświadczenia są bardzo różnorodne. Od juniorów, którzy nie znają innej rzeczywistości, przez programistów widzących wady i zalety, po tych którzy pozbyli się zupełnie PR’ów i świetnie sobie radzą.
Zacznijmy od podstaw
Czym jest pull request? To taki przystanek, na którym kod z brancha czeka, aż będzie mógł być wpuszczony do głównego repozytorium. To, czy zostanie wpuszczony może zależeć od kilku rzeczy. Mogą być uruchamiane testy automatyczne, które sprawdzają, czy kod nie zawiera regresji. Może być robiona statyczna analiza kodu z użyciem narzędzi albo code review przeprowadzane przez innych członków zespołu. GitHub na przykład w bardzo estetyczny sposób pokazuje różnicę między kodem, który w tej chwili jest w repozytorium, a tym, który ma być dodany. Jest to oczywiście na bieżąco aktualizowane i jeżeli ktoś wprowadzi swoje zmiany, to potencjalne konflikty od razu zostaną wykryte.
Co naprawdę dają nam pull requesty?
Pull request bez dwóch zdań spowalnia wejście na produkcję. Ma jednak pewne zalety. Poprawia jakość kodu, może też poprawiać bezpieczeństwo, a choćby wydajność. Zakładamy, iż proces CI/CD jest szybki, testy stabilne, a zespół projektowy efektywny. Rzeczywistość może jednak zaskoczyć. W praktyce znamy wiele przykładów, kiedy poprawka musiała czekać do kolejnego dnia na „klepnięcie” przez dwie osoby. Znamy też PRy zaakceptowane bez sprawdzania, albo takie, które wisiały przez kilka dni. Świat nie jest doskonały.
Jeśli nie pull request to co?
Problemem nie są same PRy, tylko szereg odpowiedzialności, które zepchnięto na to jedno narzędzie. Nadrabiamy nim braki w komunikacji. Mówimy, iż zmniejsza ilość błędów, ale czy ktoś to mierzy? No i możemy stworzyć proces CI/CD uruchamiając automatyczne testy i analizy przed wejściem na produkcję, bez przystanków po drodze. Code review możemy robiće przed lub po wyjściu kodu z komputera autora. Kod nie musi czekać na przystanku.
Najważniejsze nie jest to, czy zdecydujemy się na PRy czy nie. Najważniejsze jest to, czy wiemy po co używamy tego narzędzia. Co nam to realnie daje, a jakie problemy próbujemy ukryć, podpinając za dużo pod ten jeden etap procesu wytwarzania oprogramowania.
Podsumowałam naszą rozmowę o pull requestach podczas
na Instagramie. Andrzej Krzywda jako naczelny przeciwnik PRów wpadł na chwilę podyskutować
