... | @@ -2,12 +2,12 @@ Zadania (*issues* w nomenklaturze GitLab'a), dzielą się na dwie grupy. Omówim |
... | @@ -2,12 +2,12 @@ Zadania (*issues* w nomenklaturze GitLab'a), dzielą się na dwie grupy. Omówim |
|
|
|
|
|
# Badania
|
|
# 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).
|
|
* **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.
|
|
* **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.
|
|
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 |
... | @@ -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).
|
|
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.
|
|
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 |
... | @@ -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.
|
|
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`
|
|
* zachowana kolejność modyfikatorów według specyfikacji JLS np. `private static final` vs `final private static`
|
|
|
|
|
... | @@ -81,7 +81,7 @@ Oznacza to też, że zadanie zostało wykonane i możesz brać następne. |
... | @@ -81,7 +81,7 @@ Oznacza to też, że zadanie zostało wykonane i możesz brać następne. |
|
|
|
|
|
**Pytać, pytać i jeszcze raz pytać!**
|
|
**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.
|
|
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`.
|
|
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`.
|
|
|
|
|
... | @@ -89,7 +89,7 @@ Nie bójmy się pytać! Początkujący często w obawie o to, że ich pytanie zo |
... | @@ -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ś!**
|
|
**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ś!**
|
|
**Popsuj coś!**
|
|
|
|
|
... | @@ -101,8 +101,8 @@ Pracując z Git'em, nie bójmy się go. **Nie ma możliwości zepsucia czegoś n |
... | @@ -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ąć?
|
|
# 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.
|
|
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. |
|
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 |
|
\ No newline at end of file |