Zadania (issues w nomenklaturze GitLab'a), dzielą się na dwie grupy. Omówimy tutaj oba rodzaje, dowiemy się w jaki sposób powinny zostać wykonywane oraz gdzie umieszczać swoją pracę.

Badania

Pierwszy rodzaj zadań, to badania, każdy issue z dopiskiem - Badanie należy do tej grupy. Badania mogą się bardzo różnić (od zbadania czy biblioteka X pozwala na Y do postawienia klastra na paru fizycznych maszynach) , bardziej szczegółowy opis znajduje się w karcie z zadaniem, jednak można wyróżnić 3 główne grupy badań.

• Badanie XXX - pod XXX podstawiamy dowolną technologię, należy dowiedzieć się w jaki sposób (o ile w ogóle), dana technologia może się przydać w projekcie. Na pewno interesuję nas czy technologia jest open source (licencja) oraz stan projektu (ostatni commit, czy się rozwija?). Być może podczas badania, natrafisz na jej alternatywy (patrz kolejny punkt).

• Porównanie - Naszym zadaniem jest porównanie technologii, interesują nas przede wszystkim różnice a nie cechy wspólne. Porównania, dobrze jest zrealizować w tabelce.

Dwa powyższe rodzaje badań, umieszczamy tutaj na GitLab'ie w dokumentacji Wiki projektu Tabula. Wybieramy odpowiedni dział (lub tworzymy nowy, jeśli do żadnego nie pasuje) i zamieszczamy w nim naszą pracę.

Zadbajmy o formatowanie, nic szczególnego, wystarczy żeby nasz tekst nie odstraszał czytelnika.

Jeśli to możliwe to unikamy wrzucania obrazów / multimediów - zajmuje to znacznie więcej pamięci i spowalnia ładowanie dokumentów. Mamy do dyspozycji Markdown, który pozwala na stworzenie prosto czytelnych tabel lub grafów.

• PoC (proof of concept) - jak sama nazwa mówi, mamy pokazać, że się da lub nie da czegoś wykonać. To jest najważniejsze, sprawą drugorzędną jest jakość kodu, ten kod prawdopodobnie nie wejdzie na produkcję ponieważ z samego założenia, nie jest to celem zadania. Celem jest zdobycie wiedzy o danej technologii.

PoC'e najczęściej umieszczamy w nowym folderze w repozytorium projektu Tabula.

Po wykonaniu badania, zgłaszamy to na kanale #general, oznaczając @blank, podsyłamy odnośnik do wiki / repo.

Badania są relatywnie najprostszymi możliwymi zadaniami, ponieważ wymagają poznawania tylko 1 biblioteki na raz (w opozycji do używania równolegle 15 bibliotek w projekcie). Pozwalają dzięki temu zaaklimatyzować się w grupie.

Praca z kodem

Drugi rodzaj zadań, jest związany bezpośrednio z projektem. Pracujemy według Feature Brach Workflow.

Tworząc nazwę branch'a dla zadania prefiksujemy ją numerem Issue, aby w GitLabie pojawiło się powiązanie, między branch'em, a issue, czyli nazwa brancha = numer_issue-tytul

Dla przykładu, mając issue, którego numer - 9 - możemy znaleźć zaraz pod główną zakładką lub w URL'u - https://elenx.net/blank/Raicoone/issues/1, tworzymy branch 9-ftp-tests.

Jeśli nie jest to koniecznie, starajmy się nie umieszczać więcej niż 10 plików w jednym PR/MR - przyczyni się to do szybszego sprawdzenia a co za tym idzie dostaniesz szybszy feedback i nie popełnisz tych samych błędów w kolejnych. Usprawni to znacznie pracę mentorom - w przypadku małych PR'ów wystarczy 10-15 minut wolnego czasu na sprawdzenie; jeśli plików jest dużo a zadanie nie jest trywialne.

Każdy commit message powinien się zaczynać od # np #123 (closed). Pomaga to w wyszukiwaniu commitów w gicie.

MR wykonujemy z poziomu GitLaba, przypisując jako assignee któregoś z opiekunów projektu. Po tym fakcie można też poinformować go o tym na slacku.

Nasz MR możemy także oznaczyć jako WIP, kiedy wprowadzamy jeszcze pewne zmiany ale chcielibyśmy otrzymywać informację zwrotną dotyczącą jakości naszego kodu od mentora.

Merge Request = MR = PR = Pull request

Testy - piszemy testy jednostkowe. Jeśli dodajemy jakąś funkcjonalność, powinna być ona pokryta testami. Juniorów (zakładamy, że Ci bardziej doświadczeni już to robią) bardzo zachęcamy do pisania kodu zgodnie z TDD. To jasne, że na początku nie będzie łatwo :)

Sonar & Gitlab CI

Jeśli już wiesz jak wygląda praca z Git'em, opiszemy co się dzieje po wykonaniu pull request.

Nasi dwaj przyjaciele, Sonar i Gitlab CI przeanalizują Twój kod na zdalnym serwerze.

Pierwszy z nich Sonar, sprawdzi czy kod spełnia standardy zgodne z najlepszymi praktykami. Parę przykładów:

• zachowana kolejność modyfikatorów według specyfikacji JLS np. private static final vs final private static

• odwołania do obiektów które mogą posiadać wartość null

• podczas rzucania RuntimeException, zostanie nam zwrócona uwaga, żeby użyć bardziej specyficznego wyjątku np. IllegalAccessException.

Gitlab CI (Continous Integration) uruchomi wszystkie testy i spróbuje zbudować linie produkcyjną z Twoimi zmianami. Co nie oznacza, że zmiany zostały dołączone - to symulacja, żeby się upewnić, że po wprowadzeniu zmian, nic złego się nie stanie.

Na Slacku, na kanale z nazwą projektu w którym uczestniczysz (np. #epomis lub #raicoone) pojawią się notyfikację związane z pracą Jenkins.

Jeśli coś pójdzie nie tak, zobaczysz tam komunikat FAILED z czerwonym paskiem. Klikamy odnośnik Open i logujemy się za pomocą loginu i hasła znajdującego się na kanale #general w sekcji Pinned. W menu Logi konsoli zazwyczaj na samym dole, znajdziemy przyczynę. Zostanie pokazany task gradle'owy (np. :modules:persistence:compileJava FAILED) i informacja, co dokładnie poszło nie tak.

Możemy taki task powtórzyć u siebie lokalnie, wchodząc w View -> Tool Windows -> Gradle, tam odnajdujemy interesujący nas moduł i uruchamiamy odpowiedni task. Druga możliwość to uruchomienie task'a z CLI. Wpisujemy w tym przykładzie gradle :modules:persistence:compileJava

Z Sonarem jest podobnie, zostaniemy poinformowani w miejscu w którym znajduję się Pull Request. Przy którejś linijce kodu, do której Sonar ma zastrzeżenia ujrzymy komentarz wyjaśniający powód zaniepokojeń i dodatkową sugestie, jak możemy rozwiązać problem.

Zachęcamy do zainstalowania wtyczki SonarLint do IntelliJ. Dzięki temu, otrzymasz informację od Sonar'a jeszcze przed wypchnięciem kodu na serwer!

Nie traktuj uwag Sonar'a jako wyroczni, jedynej prawdziwej słusznej drogi, w 90% ma rację, jednak jeśli wydaję Ci się, że coś jest nie tak albo po prostu nie jesteś pewien jego sugestii - zapytaj na #general.

Gitlab CI z Sonarem nie maja już zastrzeżeń, co teraz?

Teraz przeglądają Twój kod mentorzy. W tym miejscu sprawdzamy czy logika kodu jest poprawna, czy zadanie zostało wykonane optymalnie. Przykładamy dużą uwagę, do jakości kodu a co za tym idzie - wiele się można nauczyć. Tak jak Sonar, zostawiamy uwagi, pod linijką kodu, do którego mamy zastrzeżenia. Jeśli nie dostatecznie dobrze został wytłumaczony błąd lub masz jakieś wątpliwości - odpowiedz pod komentarzem lub zapytaj na kanale #general.

Jeśli co najmniej dwóch mentorów zaakceptuje Twój kod, admin zostanie powiadomiony. Sytuacja wygląda tak samo jak w punkcie wyżej. To ostatni etap, jeśli Twój kod zostanie włączony na produkcje, zostaniesz powiadomiony o tym na kanale odpowiadającym nazwie projektu oraz mailowo.

Oznacza to też, że zadanie zostało wykonane i możesz brać następne.

Kto pyta nie błądzi!

Pytać, pytać i jeszcze raz pytać!

O tym dlaczego warto to robić zaraz, najpierw zastanówmy się co możemy zrobić przed zapytaniem. Możemy poszukać odpowiedzi w internecie! Może wydawać Ci się to banalne jednak rzeczywistość pokazuje, że często padają pytania, na które odpowiedzi, znajdujemy w pierwszym odnośniku pierwszej strony wyszukiwarki.

Jeśli nie znalazłeś rozwiązania w sieci, nie wiesz jak zacząć, utknąłeś lub chcesz się upewnić, że w dobrą stronę zmierzasz to zadaj pytanie na kanale #general.

Nie bójmy się pytać! Początkujący często w obawie o to, że ich pytanie zostanie odebrane jako banał wstydzą się zapytać, jest to błąd - doskonale zdajemy sobie sprawę, że ktoś dopiero zaczyna swoją przygodę. Nie ma nic złego w tym, że czegoś nie wiesz. Można ustalić sobie okienko czasowe, np. pół godziny / godzina - jeśli w tym czasie nie uda się posunąć o krok - zapytaj. Chętnie odpowiadamy i dzielimy się wiedzą, samemu przy tym się ucząc :)

Podziel się tym co znalazłeś!

Udało Ci się uzyskać jakieś ciekawe informacje do zadania? Podziel się nimi! Zapewne zdarzy się, że odpuścisz jakieś zadanie - brak czasu, chęć popracowania nad czymś innym itp. Aby informacje które znalazłeś/aś albo uzyskałeś/aś od Mentora nie przepadły, warto je zawrzeć w komentarzu do danego zadania. Jeżeli uda Ci się skończyć zadanie, to nadal warto wpisać takie informację do komentarza danego zadania. Na pewno znajdzie się osoba, która będzie chciała zrobić skończone zadanie dla samego siebie, aby się czegoś nauczyć. Dzięki takim działaniom stworzymy małą bazę wiedzy na temat zadań oraz oszczędzimy czas Mentorów co do odpowiadania na skończone zadania :)

Popsuj coś!

Mówi się, że uczymy się na błędach, a zebraliśmy się tutaj po to żeby się uczyć -> jesteśmy tutaj po to, żeby popełniać błędy.

Nie bój się czegoś zepsuć. Zauważyłeś odstępstwa od konwencji? Popraw! Uważasz, że Twoja nazwa będzie lepiej pasowała do tej zmiennej? Zmień! Masz jakiś pomysł na refactoring? Śmiało!

Pracując z Git'em, nie bójmy się go. Nie ma możliwości zepsucia czegoś na produkcji. Z naszej perspektywy nie możesz niczego popsuć, Co najwyżej możesz namieszać u siebie lokalnie - i się czegoś przez to nauczyć :) Git to bardzo elastyczne narzędzie, prawie wszystkie zmiany można odwrócić, dlatego warto eksperymentować właśnie tu z nami, Twój przyszły szef może nie być taki wyrozumiały :)

Jak konkretnie zacząć?

To, że przychodzicie do projektu który jest w pewnej części napisany i jest tak duży, że jest nieogarnialny w 100% jest całkowicie normalne. W dzisiejszych czasach firmy piszą oprogramowanie zespołowo - w dziesiątki i setki programistów. Nie ma fizycznie możliwości, by ogarnąć 100% tego.

Ja osobiście wymyśliłem zarówno Raicoone'a i Epomisa oraz sam tworzyłem jego kod od samego początku, a dziś nawet ja nie wiem jak one w pełni działają, bo zbyt dużo osób wprowadzało równoległe zmiany. :) Nie przejmujcie się tym i nie bójcie, bo to jest normalne - dlatego trzeba pisać testy jednostkowe oraz dokumentacje. Gdyby każdy mógł sobie ogarnąć 100% projektu w parę godzin, to dokumentacja byłaby totalnie zbędna.

Najważniejsze to zrozumieć ogólną ideę projektu (high level abstraction), potem zrozumieć task (po co? dlaczego?), następnie zlokalizować w kodzie adekwatne miejsce i wgłębić się tylko w tę konkretną okolicę. Po kilku taskach będziecie mieć opanowane kilka okolic, co daje już niezłe wyobrażenie o systemie jako całości, ale to nadal tylko wyobrażenie.