Jednym z obowiązków team lidera jest kontrola kodu, który ma być wdrożony do kierowanej przez niego aplikacji. Jego zadaniem jest pilnowanie wysokiej jakości kodu wytwarzanego przez jego zespół. Ma on wiele narzędzi, które pomagają mu nad tym czuwać. Jednym z nich jest git i Pull request.

Oczywiście Pull requesty nie są jedynie sprawą team lidera. Każdy programista, niezależnie czy junior, czy senior, wystawiając swój kod musi starać się, aby był on jak najlepszej jakości. Nie jest to narzędzie do wytykania sobie błędów w negatywnym tego słowa znaczeniu, ale do wzajemnej nauki i zwykłej weryfikacji. Błąd każdemu może się zdarzyć a po co to odkryć dopiero na produkcji.

Pull request – co to jest?

Pracujemy nad kodem i przychodzi czas, aby go opublikować. Odpalamy git push i co dalej? No właśnie Pull Request. Dobrą praktyką jest, aby zespół robił sobie wzajemnie code review. Aby osoby z teamu mogły zobaczyć dokładnie to, co stworzyłeś, a nie przeglądać całego kodu w poszukiwaniu ostatnich zmian tworzymy właśnie PR. GitHub czy Bitbucket to narzędzia, które wychodzą o krok dalej i dają nam piękny interfejs graficzny jeszcze bardziej uprościć nam codzienną pracę.

Pull request to więc nic innego jak wygenerowanie widoku w wybranym narzędziu, które pokazuje zmiany w kodzie, które chcemy wprowadzić. Używa się go do przedstawienia kodu zespołowi, aby mógł go ocenić na code review.

Work flow

Używanie PR w codziennej pracy to bardzo dobra praktyka, która sprawdza się zarówno w małych, jak i większych zespołach. Po każdym zrealizowanym zadaniu powinien pojawić się PR, który powinni ocenić wszyscy członkowie zespołu. Dodać swoje komentarze lub zaakceptować zmiany. 

Gdy wszystkie osoby dołączone jako reviewers do danego PR dadzą approve, kod może zostać zmergowany do brancha rozwojowego lub innego w zależności od typu zadania. Do jakiego dokładnie to temat innego nadchodzącego posta. 

Tak więc kończymy zadanie -> PR -> approve od każdego członka zespołu -> merge. Pewnie nasuwa Ci się pytanie, ale dlaczego od każdego, a nie np. od jednego? Przecież to strasznie spowolni wrażanie zmian.

Z kilku powodów:

  1. Rozpowszechnianie wiedzy o zmianach, jakie są wdrażane. Dobrze, aby każdy wiedział co wchodzi, bo możemy ustrzec się przed niepotrzebnie spalonym czasem, bo dwie osoby zrobią to samo albo konfliktami przy mergowaniu.
  2. Juniorzy mogą nauczyć się wielu rzeczy, szczególnie architektonicznych. Młodzi programiści, nawet jeśli nie znajdą błędu, to analizując kod starszych kolegów, mogą się wiele nauczyć. Poznać rozwiązania, zastosowania czy mechanizmy frameworka. Dodatkowo są na bieżąco z rzeczami podstawowymi, o których bardziej doświadczeni programiści mogą zapomnieć.

Zdrowe podejście

Niezależnie czy jest się seniorem, czy juniorem, każdy powinien wystawiać swój kod do CR z użyciem PR. Tak jak pisałam w artykule o code review nie jest to narzędzie do wytykania błędów innym, żeby udowodnić ich niewiedzę. Czy dokopanie drugiemu, aby mu pocisnąć w konfliktowej sytuacji. PR jest po to, aby uchronić się przed błędami na produkcji. Aby nauczyć się nowych rozwiązań. Mieć świadomość, w jaki sposób rozwija się nasz aplikacja.

Grunt to nie dać się zwariować.

PR – Bitbucket

Przedstawiony przykład jest wygenerowany na podstawie mojego projektu eCeremoniarz. 

Będąc w kontekście repozytorium kliknij zakładkę Pull requests (Bitbucket 1). Pojawi Ci się lista wszystkich PR, które są aktualnie wystawione do oceny.

W prawym górnym rogu znajdziesz przycisk Create pull request. Kiedy w niego klikniesz, aplikacja przeniesie Cię na widok tworzenia PR (Bitbucket 2).

Z lewej strony wybierasz branch, na który wypchnąłeś zmiany.  Z prawej branch, do którego chcesz zmergować swój feature branch. Przykład przedstawia wyrównanie developa do mastera. To nie jest prawidłowe git flow, wiem, zostało to wygenerowane tylko dla przykładu. O git flow będzie innym.razem.

Dodatkowo dla PR możesz ustawić tytuł, dobrze żaby zawierał on numer wykonywanego zadania i jedno zdanie mówiące czego dotyczą zmiany. Opis, który jest najczęściej generowany z komentarzy do wszystkich commitów.

Do Reviewers powinieneś dodać cały zespół lub osoby ustalone, które powinny zobaczyć i ocenić ten PR. Opcja close branch to informacja o tym, czy po zmergowaniu tego PRa branch, który jest mergowany (po lewej stronie) ma być usunięty.

Kiedy wszystko już skonfigurowałeś, możesz spokojnie kliknąć Create pull request pod formularzem. Kolejny widok to już gotowy PR, który widzą inni członkowie zespołu (Bitbucket 3). To podsumowanie zawierające wszystkie potrzebne informacje do wykonania code review. Osoby oceniające oprócz dodania komentarzy do każdej z linii kodu powinni kliknąć approve, kiedy zmiany są dla nich ok.


PR – GitHub

W GitHubie tworzenie PR wygląda analogicznie:

Kliknij zakładkę Pull requests (GitHub 1). Następnie po prawej stronie zobaczysz wielki zielony przycisk New pull request. Wybierasz branche, które chcesz porównać i gotowe.  

Pull requesty to bardzo przydatne narzędzie, którego wykorzystywanie w codziennej pracy powinno być standardem. Jeśli pracujesz jako programista, to dobrze o tym wiesz, ale jeśli dopiero zaczynasz, to pamiętaj, że PR nie służą, aby pocisnąć drugiej osobie, ale aby się wzajemnie uczyć i współpracować.

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

  1. Team Leader jest od akceptowania pull requestów i kontroli jakości? Z tym się nie zgadzam. TL niekoniecznie musi być najlepszym programistą.
    Moim zdaniem cały zespół jest ospowiedzialny za jakość. Dobrym programistom będzie zależało, żeby była ona coraz lepsza. Warto też przyjąć zasadę dwóch code review. W moim zespole w pewnym momencie zaczęliśmy ją stosować i okazało się, że o wiele więcej rzeczy było wyłapywanych podczas tego etapu, jakość wzrosła.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here