GIT, a praca zespołowa

Dzisiaj dość miękki wpis na temat tego jak GIT pomaga w pracy zespołowej. Kontynuuję tutaj wpis z instagrama, bo tam zabrakło mi miejsca 😉

Merge Request

Nie będę tutaj rozpisywać się o tym, że każde osobne zadanie to osobny branch, każdy pracuje na swoim branchu czy o tym jak wykonać rebase czy merge. Zajmiemy się samym końcem prac nad zadaniem czyli merge requestem bądź pull requestem. W zależności od tego czy korzystasz z gilaba czy z githuba. Jedno i drugie działa bardzo podobnie. Ja wykorzystuje w pracy gitlaba więc na tym przykładzie będę wszystko opisywać.

Także Merge Request (MR) jest żądaniem wdrożenia naszych zmian do innej gałęzi kodu (zazwyczaj main/master oraz deploy na produkcje). Zaraz po wypuszczeniu pierwszego commita dostajemy możliwość utworzenia takiego MR i tutaj jest już pierwsza ważna kwestia. Jeśli tworzysz taki MR od razu z rozpoczęciem prac to pamiętaj, aby w tytule dopisać Draft: lub WiP (work in progress). Dzięki temu Gitlab czy Github zablokuje opcję merga i przez przypadek nikt nie wypuści niesprawdzonych zmian do głównej gałęzi.

Jednak przejdźmy dalej. Masz już gotową funkcjonalność, opisałeś poprawnie swojego merge request’a (jak opisać poprawnie jest troszkę niżej) i trzeba przekazać kod do sprawdzenia innym programistom. Więc przechodzimy do procesu nazywanego Code Review.

Code Review

Code Review ( lub ogólnie przyjęty skrót CRk’a) to po prostu przegląd kodu. W zależności od ustalonych zasad w firmie/zespole są wyznaczone osoby, które ten kod sprawdzają. Jak pracowałem w kilku firmach to zazwyczaj taką CRk’ę wykonywały następujące grupy osób:

  • Seniorzy – osoby z najwięszkym doświadczeniem, które najlepiej znały kod
  • Team Lider – w zespołach gdzie team lider był też programistą to on wykonywał CR
  • Moje ulubione podczas daily rozdajemy zadania do CR wśród wszystkich programistów i drugie CR idzie do seniora/teamlidera

Jeszcze tutaj wtrącę o tym punkcie trzecim dlaczego ja go uważam za ulubione i najlepsze. Dzięki temu rozwiązaniu inni programiści poznają większą ilość kodu w projekcie i ich wiedza na temat procesów następujących w kodzie jest dużo większa (może i płytka jest ta wiedza, ale na tyle szeroka, że przy wdrażaniu innych zmian programista ma świadomość czy jego zmiany mogą mieć wpływ na całkowicie inną część kodu – oczywiście pomijamy tutaj kwestie single responsibility, tylko bierzemy same kwestie biznesowe gdzie procesy się muszą zazębiać).

Code Review polega na tym, że inny programista przegląda Twój kod i wyszukuje potencjalnych błędów oraz sugeruje różnego rodzaju zmiany optymalizacyjne. Pamiętaj code review to jest merytoryczna dyskusja, a nie wywyższanie się nad kolegą z zespołu. W zależności od tego jak code review przebiega mogą pojawić się w nim różnego rodzaju dyskusje i sugestie, które należy rozwiązać.

Jako rozwiązanie dyskusji przyjmuje się wyczerpanie tematu jeżeli jest to pytanie dotyczące jakiegoś wycinka kodu bądź naniesienie odpowiednich poprawek w kodzie. Taką dyskusję rozwiązuje jej autor, dzięki czemu wiadomo, że zmiany zostały przez niego zaakceptowane.

Na sam koniec po rozwiązaniu wszystkich dyskusji programista, który ten kod przejrzał (i jeśli nie ma testerów w zespole) dokładnie przetestował to daje approve. Po zebraniu odpowiedniej ilości approve (ile ich potrzebujesz zależy od tego jak się dogadaliście w zespole) możesz wdrożyć swoje zmiany na produkcje, kończąc tym cały praces.

Jak powinien wyglądać Merge Request?

W zależności od tego co macie ustalone w zespole, można wyciągnąć kilka wspólnych założeń, które pojawiają się zawsze i są to:

  • Tytuł MR jest krótki i spójny. W razie potrzeby ma odpowiedni dopisek Draft bądź WiP
  • W opisie MR najlepiej jak umieścisz link do zadania, którego on dotyczy. Dzięki czemu tester bądź programista może szybko przenieść się i poznać szczegóły dlaczego zaszły te zmiany.
  • Opisz treściwie co Twoje zmiany powodują i dlaczego one zaszły
  • Jeśli MR dotyczy bug’a dobrze, abyś opisał jak go odtworzyć oraz dlaczego poprawiłeś go w taki a nie inny sposób.
  • Zmiany zawarte w MR są w miarę możliwości jak najmniejsze, dzięki czemu review będzie dokładniejszy.
  • Kod w MR jest przez Ciebie sprawdzony i przetestowany. Twoje zmiany przeszły przez analizę statyczną kodu i spełnia wszystkie założenia zadania.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *