Piszemy kod

14.1 Zwykły dzień z życia programisty

Bycie programistą to łatwa i przyjemna sprawa. Organizacją pracy zajmuje się Project Manager, za listę funkcji produktu odpowiada Product Owner. Spotkania organizuje Scrum Master. Wszystkie procesy organizacyjne są maksymalnie sformalizowane i standaryzowane.

Przychodzisz rano do pracy, robisz sobie herbatkę albo kawę i siadasz przy komputerze. Otwierasz czat, patrzysz, czy nie ma pilnych wiadomości, czy ktoś nie zachorował i jeśli wszystko jest w porządku, to zabierasz się do pracy.

Otwierasz stronę JIRA, na której znajduje się lista wszystkich zadań twojego zespołu: backlog projektu i backlog bieżącego sprintu. Zadania są już posortowane według priorytetów przez Twojego Scrum Master/TeamLeadera lub Product Ownera.

Bierzesz zadanie z samej góry — najbardziej priorytetowe — i zaczynasz nad nim pracować. Aby to zrobić, musisz zmienić status na In Progress. Robi się to kilkoma kliknięciami. Czas start.

Do opisu zadania zwykle dodawana jest dodatkowa informacja lub link do dokumentacji. Zadanie musi zawierać wszystkie niezbędne informacje, abyś mógł je wykonać. Zapewnienie tej informacji to zadanie twojego menedżera.

Jeśli coś jest nie tak, możesz przypisać zadanie (task) swojemu menedżerowi i napisać w komentarzach, jakie pojawiły się pytania i/lub jakiej informacji brakuje.

14.2 Piszemy kod

Przestudiowałeś opis zadania i rozumiesz, co trzeba zrobić. Super, zaczynaj pracę. Tutaj pomoże Ci Twoje doświadczenie zdobyte podczas nauki na CodeGym, praca w zespole.

Po tym jak kolejna funkcja jest gotowa i jesteś tego pewien, musisz wrzucić swój kod na Git. Robi się to kilkoma kliknięciami bezpośrednio z IDE. W Twoim przypadku z WebStorm. Komitujesz swój kod najpierw do lokalnego repozytorium, a potem puszujesz (push) go do centralnego repozytorium Git.

Najczęściej ostatnia operacja odbywa się za pomocą Pull Request, kiedy poprzez Git wysyłasz zapytanie do swojego TeamLeadera o przegląd kodu. Jeśli z kodem wszystko jest w porządku i nie ma żadnych uwag, Twój TeamLeader zaakceptuje (accept) Twój pull request i trafi on do głównej gałęzi roboczej git.

Nie warto też przychodzić do TeamLeadera z frazą „tego nie da się zrobić”. Taka fraza bardzo irytuje, zwłaszcza gdy TeamLeader dokładnie wie, że „tak da się zrobić” i sam być może robił coś podobnego wiele razy.

Nie wiesz, jak zrobić – powiedz: „spędziłem dwie godziny/dwa dni próbując rozgryźć jak to zrobić, ale mi się nie udaje”. TeamLeader z przyjemnością podpowie Ci… w jakim kierunku googlować.

Przeszliśmy teraz przez obraz współczesnego tworzenia produktu. Pisanie kodu to tylko mała część całej pracy, ale wszystko jest zorganizowane tak, żeby nic nie rozpraszało Cię od pracy. Więc śmiało przechodź do nauki Frontendu — praca programisty Ci się spodoba.