... | ... | @@ -2,12 +2,12 @@ Zadania (*issues* w nomenklaturze GitLab'a), dzielą się na dwie grupy. Omówim |
|
|
|
|
|
# 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 znajduję się w karcie z zadaniem, jednak można wyróżnić 3 główne grupy badań.
|
|
|
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 pasuję) i zamieszczamy w nim naszą pracę.
|
|
|
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.
|
|
|
|
... | ... | @@ -25,9 +25,9 @@ Badania są relatywnie najprostszymi możliwymi zadaniami, ponieważ wymagają p |
|
|
|
|
|
Drugi rodzaj zadań, jest związany bezpośrednio z projektem. Pracujemy według [Feature Brach Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow).
|
|
|
|
|
|
Tworząc nazwę branch'a dla zadania prefikujemy ją numerem Issue, aby w GitLabie pojawiło się powiązanie, między branch'em, a issue, czyli nazwa brancha = `numer_issue-tytul`
|
|
|
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](https://elenx.net/blank/Raicoone/issues/9), którego numer - 9 - możemy znaleźc zaraz pod główną zakładką, lub w URL'u - `https://elenx.net/blank/Raicoone/issues/1`, tworzymy branch `9-ftp-tests`.
|
|
|
Dla przykładu, mając [issue](https://elenx.net/blank/Raicoone/issues/9), 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.
|
|
|
|
... | ... | @@ -47,7 +47,7 @@ Jeśli już wiesz jak wygląda [praca z Git'em](https://www.atlassian.com/git/tu |
|
|
|
|
|
Nasi dwaj przyjaciele, [Sonar](https://www.sonarqube.org/) i [Gitlab CI](https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) przeanalizują Twój kod na zdalnym serwerze.
|
|
|
|
|
|
Pierwszy z nich **Sonar**, sprawdzi czy kod spełnia standardy zgodne z najlepszymi praktykami. Pare przykładów:
|
|
|
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`
|
|
|
|
... | ... | @@ -89,7 +89,7 @@ Nie bójmy się pytać! Początkujący często w obawie o to, że ich pytanie zo |
|
|
|
|
|
**Podziel się tym co znalazłeś!**
|
|
|
|
|
|
Udało Ci się uzyskać jakieś ciekawe informację do zadania? **Podziel się nimi!** Za pewne zdarzy się, że odpuścisz jakieś zadanie - brak czasu, chęć popracowania nad czymś innym itp. Aby informację które znalazłeś/aś albo uzyskałeś/aś od Mentora nie przepadły, warto ją 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 :)
|
|
|
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ś!**
|
|
|
|
... | ... | @@ -101,8 +101,8 @@ Pracując z Git'em, nie bójmy się go. **Nie ma możliwości zepsucia czegoś n |
|
|
|
|
|
# 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.
|
|
|
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. |
|
|
\ No newline at end of file |
|
|
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. |
|
|
\ No newline at end of file |