... | @@ -90,3 +90,17 @@ Mówi się, że uczymy się na błędach, a zebraliśmy się tutaj po to żeby s |
... | @@ -90,3 +90,17 @@ Mówi się, że uczymy się na błędach, a zebraliśmy się tutaj po to żeby s |
|
Nie bój się czegoś zepsuć. Zauważyłeś odstępstwa od [konwencji](http://elenx.net/blank/Docs/wikis/Pierwsze-kroki/2.-Konwencja)? Popraw! Uważasz, że Twoja nazwa będzie lepiej pasowała do tej zmiennej? Zmień! Masz jakiś pomysł na refactoring? Śmiało!
|
|
Nie bój się czegoś zepsuć. Zauważyłeś odstępstwa od [konwencji](http://elenx.net/blank/Docs/wikis/Pierwsze-kroki/2.-Konwencja)? 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 :)
|
|
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, ze przychodzicie do projektu ktory jest w pewnej czesci napisany i jest tak duzy ze jest nieogarnialny w 100% to jest calkowicie normalne
|
|
|
|
w dzisiejszych czasach firmy pisza oprogramowanie zespolowo
|
|
|
|
w dziesiatki i setki programistow
|
|
|
|
nie ma fizycznie mozliwosci by ogarniac 100% tego
|
|
|
|
ja osobiscie wymyslilem zarowno raicoona jak i epomisa oraz sam tworzylem jego kod od samego poczatku, a dzis nawet ja nie wiem jak one w pelni dzialaja, bo zbyt duzo osob wprowadzalo rownolegle zmiany :slightly_smiling_face: nie przejmujcie sie tym i nie bojcie bo to jest normalne
|
|
|
|
dlatego trzeba pisac testy jednostkowe oraz dokumentacje
|
|
|
|
gdyby kazdy mogl sobie ogarnac 100% projektu w pare godzin to dokumentacja bylaby totalnie zbedna
|
|
|
|
najwazniejsze to zrozumiec ogolna idee projektu (high level abstraction), potem zrozumiec task (po co? dlaczego?), nastepnie zlokalizowac w kodzie adekwatne miejsce i wglebic sie tylko w ta konkretna okolice
|
|
|
|
po kilku taskach, bedziecie miec opanowane kilka okolic
|
|
|
|
co daje juz niezle wyobrazenie o systemie jako calosci
|
|
|
|
ale to nadal tylko wyobrazenie |
|
|
|
\ No newline at end of file |