Duży projekt - jak sie w nim połapać?

Question

Dzień dobry,

Udało mi się załapać na staż jako młody programista php. Platforma przy, której pracuje to mocno rozbudowany projekt, nie korzystaja z żadego frameworka poza własnym, wzorzec programowy to zmodyfikowany MVC.

Cieżko mi się połapać w tym projekcie, w katalogach, plikach itd
Jeżeli chodzi o kod to przy funkcjach brakuje opisu więc pozostaje czytanie kodu i ciągłe skakanie między plikami i zagłębianie się w co raz to dalsze zakątki aplikacji i sprawdzanie klas.

Czy ktoś doświadczony nie chciałby się może podzielić jakimiś radami, które mógłby wykorzystać?

Answer 1

Cieżko mi się połapać w tym projekcie, w katalogach, plikach itd 

Spoko, to przyjdzie z czasem :) Przy większych projektach trzeba czasu na wdrożenie, tak mniej więcej po 3-4 miesiącach zaczniesz się w miarę swobodnie czuć w wycinku projektu, w którym głównie będziesz siedział.

Jeżeli chodzi o kod to przy funkcjach brakuje opisu

W dobrym kodzie nie musi być żadnych komentarzy i opisów. Dlatego tak ważne jest tworzenie dobrych i jasnych nazw metod, funkcji, zmienych itp. o czym niestety wiele początkujących osób zapomina. Na przykład zamiast robić funkcję price(), która nic kompletnie nie mówi, zrób funkcję getPriceWithRebate() itp. itd. Ponad to tworzy się proste funkcje, unika się side-effects itp.

ciągłe skakanie między plikami i zagłębianie się w co raz to dalsze zakątki aplikacji i sprawdzanie klas

No to Cię pocieszę... tak jest, było i będzie przez całą Twoją karierę :) Nawet jeśli dzisiaj zgłębisz dokładnie kod jakiegoś fragmentu to za miesiąc okaże się, że ktoś inny robił tam zmiany i gdy ponownie wejdziesz aby dorobić jakiś ficzer będziesz musial przekopać się przez obcy Ci kod :) 

Dlatego ważne jest, aby w miarę możliwości czasowych przeglądać pull requesty w usługach które utrzymujesz, nawet jeśli nie analizujesz dokładnie to chociaż luknij co ktoś dodaje aby wiedzieć co się dzieje w kodzie :)

Czy ktoś doświadczony nie chciałby się może podzielić jakimiś radami, które mógłby wykorzystać?

Wyluzuj, to po pierwsze :) i po drugie śmiało pytaj w firmie, ale też staraj się szukać rozwiązań sam. To znaczy, np. jeśli nie wiesz jak przeiterować po tablicy i wywołać na każdym elemencie callback to nie zawracaj tym głowy innym, to znajdziesz łatwo w docs czy na SO. Ale jeśli np. nie umiesz odpalić planu builda na bamboo, zmodyfikować zadania na JIRZE itp. itd. to o takie rzeczy śmiało pytaj, bo to są narzędzia, których masz pełne prawo nie znać.

Także głowa do góry i powodzenia !

Comments

tak na maginesie, polecam poczytać: https://helion.pl/ksiazki/czysty-kod-podrecznik-dobrego-programisty-robert-c-martin,czykov.htm#format/d

Gdy uczysz się w domu sam dla siebie to nie zawsze chce Ci się stosować do tych zasad opisnaych w książce, bo kto będzie w domu tracił 15 minut na dobranie nazwy funkcji :) ? Ale w pracy te 15 minut oszczędzi Tobie i innym w przyszłości pół godziny szukania co do czego :)

Moim zdaniem to ważna pozycja dla każdego programisty.

---

super, bardzo dziękuje za odpowiedź, uspokoiłeś mnie bardzo :)

oczywicie o sprawy programistyczne nie pytam, rozwiązań szukam sam ale aplikacja jest spora, ma wiele modułów i czasami musze spytac jak cos działa od strony panelu bo inaczej spedziłbym nad tym kilak godzin, a jest to 5 minut tłumaczenia

---

No to Cię pocieszę... tak jest, było i będzie przez całą Twoją karierę :) Nawet jeśli dzisiaj zgłębisz dokładnie kod jakiegoś fragmentu to za miesiąc okaże się, że ktoś inny robił tam zmiany i gdy ponownie wejdziesz aby dorobić jakiś ficzer będziesz musial przekopać się przez obcy Ci kod :) 

Mocno nieprawda. To zależy od firmy, projektu i podejścia zespołu.

po drugie śmiało pytaj w firmie

Niestety z tym też bywa różnie. Są fajne zespoły, są też gbury. ​​​​​

---

z pierwszym w sumie racja choć różnie to bywa, a co do drugiej kwestii to już zależy od czlowieka, ja mam jasną zasade: liczy się najpierw ciekawy projekt i atmosfera a dopiero potem kasa. Jeśli ktoś patrzy tylko na kasę w pracy to nie zawsze jest to dobre... a jak sie nie podoba klimat w firmie to przeciez pracy dziś nie brakuje :) ja zawsze powtarzam ze nie ma nic gorszego niz siedziec w firmie i pracy ktorej nie lubisz.

Answer 2

Tak to już jest jak wrzuca sie ludzi na nagły skok poziomu wiedzy

Czasami tak po prostu jest że wchodząc do projektu jest różnica między poziomem wymaganym do zrozumienia jak to działa
A poziomem jaki aktualnie masz

Ale to jest super, bo wtedy bardzo szybko się uczysz nowych rzeczy

Od siebie mogę powiedzieć => nie ucz się całego projektu, bo i tak nigdy się nie nauczysz
Tylko ucz się stylu pisania kodu przez innych ludzi w zespole
Jakie wzorce lubią, jakim schematem jest tworzona architektura

Dużo większą wartością jest wiedza gdzie czegoś szukać, niż wiedza w którym pliku w której linijce jest jakaś metoda i jakie wartości przyjmuje, co zwraca

A samo szukanie wcale nie jest jakieś trudne, po kilku dniach idzie ogarnąć schemat
Np jeśli wiesz że wewnątrz folderu z obiektem domenowym jest folder z serwisami, które operują na tym obiekcie domenowym
To szukając kodu podejmującego decyzje "czy wysłać maila z ostrzeżeniem, że ten produkt jest mało zyskowny" szukaj w okolicach obiektu produktu, albo opłacalności

A tak poza tym to ucz się wzorców
różnego rodzaju dependency injection, strategie, buildery, command-handlery itd są używane masowo
do tego poczytaj o zasadach solid, żeby później nie robić masy poprawek do zadań
szczególnie o SRP - pojedyncza odpowiedzialność

No i pytaj jak czegoś nie wiesz
Jeśli coś dotyczy elementu języka postaraj się znaleźć problem sam, ale jeśli czujesz że to zbyt niszowy temat (np element o którym są 3 posty w internecie, z czego 2 z 2002 a trzeci z 2010, w dodatku nie na temat)
Albo coś jest związane z akurat tą aplikacją i szukanie w internecie nie ma sensu
To pytaj osób które są już w projekcie

Zdarza się tak, że w projekcie używa się elementu języka o którym zbyt dużo nie wiadomo w internecie, ale akurat w tym projekcie dobrze się sprawdza
Znalezienie informacji o nim + zrozumienie zajmie ci 2-3godziny, a to temat do wytłumaczenia w minute

+taka rada, przed rozpoczęciem zadania które wydaje sie ogromne, warto zapytać czy jest już do tego jakiś kod
czytając opis zadania czasami pojawia się myśl, że to pewnie zadanie które zajmie większość tygodnia
a w praktyce cały kod jest już napisany, a ty masz dodać tylko drobną poprawke, która zajmie ci 15-20 minut

Answer 3

To normalne. Czytaj kod i z czasem będziesz co raz lepiej zorientowany. A jak możesz to pytaj współpracowników. Na pewno nie będzie to źle postrzegane. Tym bardziej że jedno pytanie może ci zaoszczędzić kilka godzin czytania kodu.