... | ... | @@ -93,29 +93,8 @@ Pracując z Git'em, nie bójmy się go. **Nie ma możliwości zepsucia czegoś n |
|
|
|
|
|
# Jak konkretnie zacząć?
|
|
|
|
|
|
to, ze przychodzicie do projektu ktory jest w pewnej czesci napisany i jest tak duzy ze jest nieogarnialny w 100%
|
|
|
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 jest calkowicie normalne
|
|
|
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.
|
|
|
|
|
|
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 |
|
|
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 |