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?
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?
code review powinien być robiony zawsze, niezależnie od stopnia programisty tworzącego kod
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ąć.
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
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?
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.
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ść.
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.
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ą.
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!
To poproś o code review?
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.