Hej,
Dwa miesiące temu zacząłem pracę jak Junior i do tej pory miałem jeden code-review. Było to po dwóch tygodniach i od tamtej pory nie mam pojęcia czy to co pisze jest spoko, czy jest totalną kupą. Na prośbę o kolejny pół miesiąca temu usłyszałem, że nie ma czasu, bo kończy się projekt. I tu moje pytanie czy czekać kolejne kilka miesięcy, z nadzieja, że coś się zmieni, czy już szukać czegoś nowego - za miesiąc kończy mi się okres próbny i mógłbym po prostu nie przedłużać. Jak częsty powinien być code-review dla początkujących juniorów?
1
0
Pracuj tam, ale w międzyczasie szukaj nowej. Kasa nie wszystko - fajnie się czegoś uczyć nowego cały czas i dostawać rzetelny feedback o tym co robisz, inaczej trudno się rozwijać, zwłaszcza jako junior - skąd masz wiedzieć co zrobiłeś fajnie a co nie?
8
code review powinien być robiony zawsze, niezależnie od stopnia programisty tworzącego kod
2
Code review być powinien, nie tylko dla juniora (chociaż nie jestem zwolennikiem super ścisłego code review, bo to potem zatrzymuje pracę projektu, jeśli pull requesty wiszą do sprawdzenia, a nikt nie ma czasu ich przejrzeć).
Było to po dwóch tygodniach i od tamtej pory nie mam pojęcia czy to co pisze jest spoko, czy jest totalną kupą.
To nie skupiaj się tylko na sobie. Swój kod ciężko czasem ocenić, ale będąc w projekcie zapewne widzisz, co zostało napisane do tej pory (przez inne osoby) i też możesz podpatrzyć rozwiązania innych osób i możesz się albo inspirować albo patrzeć czego unikać, jak się napatrzysz na jakiś spaghetti kodzik. I tym sposobem również twoje skille mogą wzrosnąć.
0
LukeJL napisał(a):
Code review być powinien, nie tylko dla juniora (chociaż nie jestem zwolennikiem super ścisłego code review, bo to potem zatrzymuje pracę projektu, jeśli pull requesty wiszą do sprawdzenia, a nikt nie ma czasu ich przejrzeć).
Code review można robić post commit
0
W firmie z której właśnie odchodze uprawia się "wiwisekcje" na kodzie. To znaczy, że jeden pull request jest wielokrotnie "rozdrapywany", a każde wprowadzenie poprawek nie zamyka CR, a wręcz przeciwnie, generuje jeszcze bardziej dogłębne zmiany w kodzie. Jak się nietrudno domyśleć, strasznie taki proceder opóźnia wykonanie zadania. U was też tak jest, że jeden pull request ma ok. 105-200 komentarzy? Rekord to podobno 400 komentarzy w jednym pull request. Czy to normalne?
2
Moim zdaniem warto żebyś się rozejrzał za czymś innym. Na początku mojej kariery code review od seniorów był bezcenny. Wiele w ten sposób można się nauczyć jak ktoś Ci wyjaśni jak można to było zrobić lepiej itd.
0
Termit niedzielny napisał(a):
W firmie z której właśnie odchodze uprawia się "wiwisekcje" na kodzie. To znaczy, że jeden pull request jest wielokrotnie "rozdrapywany", a każde wprowadzenie poprawek nie zamyka CR, a wręcz przeciwnie, generuje jeszcze bardziej dogłębne zmiany w kodzie. Jak się nietrudno domyśleć, strasznie taki proceder opóźnia wykonanie zadania. U was też tak jest, że jeden pull request ma ok. 105-200 komentarzy? Rekord to podobno 400 komentarzy w jednym pull request. Czy to normalne?
U mnie rekord to 20, ale to Hindus pisał, na dodatek to był jego pierwszy task w projekcie, i było to de facto rozszerzenie funkcjonalności o 50%.
Ile linijek kodu jest w takim PR, że jesteście w stanie zmieścić tam 100 komentarzy?
I należy pamiętać, że jeśli komentarze sugerują zmiany wychodzące poza zakres taska (np. zmianę rzeczy, które w kodzie były już wcześniej), to się na to robi nowe taski, a nie ciągnie jeden w nieskończoność.
3
W porządnym projekcie zespołowym każda zmiana powinna przejść przez code review i to jak najszybciej, żeby uniknąć problemów z późniejszą integracją, konfliktami, etc. Niezależnie od tego, czy ktoś ma 4 dni czy 40 lat doświadczenia. Dzięki temu każdy może poznać code-base projektu, dowiedzieć się, co się w nim dzieje, jakie zmiany dochodzą, czegoś nauczyć i każdy też popełnia błędy, które inni mogą wychwycić. Bez code review w zasadzie zadanie można uznać za niezrealizowane, a miesiąc na zrealizowanie pojedynczego małego lub średniego zadania, to zdecydowanie za długo.
3
Junior powinien dostać wsparcie od lidera i kolegów z zespołu. Jeżeli koledzy nie kwapią się do pomocy i ciągle nie mają czasu to czym prędzej się zawijaj z tej firmy, ponieważ nic się nie zmieni. Ponadto code review to nie wszystko. W code review dostaniesz co najwyżej uwagi do jakiś fragmentów kodu, ale niekoniecznie dzięki nim poprawi się twój warsztat. Jeżeli lider i koledzy nie poświęcają czasu juniorom nie siedzą z nimi, nie tłumaczą, bo gonią ich terminy, to nie rozwiniesz się za bardzo w takiej firmie. Zwijaj manatki.
Jako junior miałem szczęście trafić do świetnych firm, gdzie byli świetni ludzie, którzy mieli czas i cierpliwość. Poza tym, że mieli zapał "pedagogiczny", to jeszcze byli wybitnymi specjalistami. Dzięki nim nauczyłem się mnóstwo rzeczy, których nie dowiedziałbym się z żadnej książki. Przekonałem się z przykrością, że nie jest tak w każdej firmie. W niektórych firmach pracują ludzie, którzy są kiepscy, albo nie mają chęci dzielenia się wiedzą.
0
Dzięki za odpowiedzi!
Mój problem polega głównie na tym, że robię green field - dodaje CRUDa nowej funkcjonalności do dużego systemu, przy czym całe repozytorium, do którego mam dostęp to właśnie to co wyrzeźbiłem + cześć front-endowa w js, którą piszę kolega przyjęty chwilę po mnie (on nie miał żadnego code-review). Więc w zasadzie nie mam skąd czerpać wiedzy.
Chyba najlepiej zrobię jak owocniej wykorzystam ostatni miesiąc okresu próbnego ;)
Jeszcze raz dzięki za komentarze!
0
To poproś o code review?
4
Tak jak już niektórzy wspomnieli- code review nie powinien dotyczyć tylko juniorów. Review jest często błędnie postrzegany jako proces pilnowania kodu młodszych programistów przez bardziej doświadczonych. Nic bardziej mylnego. Oczywiście to również jest jednym z elementów Code reviews, ale w dobrze zorganizowanym zespole jest to również proces dzielenia się doświadczeniem, spostrzeżeniami i radami. W przypadku doświadczonych programistów chodzi o poznanie opinii innych, zastąpienie danego kodu czymś innym itp. W przypadku juniorów wykonujących review innych programistów to proces nauki - junior powinien zapoznać się z wymaganiami dla danej zmiany i zrozumieniem co i dla czego zrobił programista.
Jeśli chodzi o Ciebie- jeśli masz możliwość to zmień, jeśli nie to oczywiście że zostań bo nawet takie doświadczenie jest lepsze niż żadne.