Robię błędy (junior)

0

siema ;]
mam stażu pół roku jako junior w bakendzie (java)
nie mam strasznie trudnych zadań, czasem zad na dzień/tydzień, a czasem te większe na miesiąc
co mnie denerwuje, to to że wale byli
firma nie jest duża, mimo, że to korpo. w naszym dziale jest około 100 osob. zespol 20 osob, z czego 10 backend i 10 front
w backendzie, dzieli sie to tez na podzespoły po 5 osob ;]
i... tutaj jest mniej wiecej podzial 3 juniorow, regular i senior
senior co jakis czas sprawdza zadania po mnie, no i...
zdarzaja sie zwrotki co jakis czas, nawet zadania z przed miesiąca - dwóch
troche siara, bo on to testuje i wywala mu na jakiejś głupocie - ja to zawsze testuje, ale potem wprowadze zmiany do jakiś większych funkcjonalności, a te małe zaś przestaną działąć...

czy to normalne ze robie czasem byki?
czy wy jako seniorzy dostajecie białej gorączki przy sprawdzaniu zadań / kodu po juniorach i nagle coś się wywala : )?

3

Pisz unit testy do malych rzeczy, to zlapiesz jak zaczna sie wywalac.

0

Od tego masz seniora, żeby wyłapał dlaczego się tak dzieje i coś na to zaradził.

0

Warto abyś wynosił z każdego błędu jakąś lekcję, a nie olewał sprawę (bo junior, bo ktoś poprawi, bo błąd)

Z tego co piszesz to nie jest za kolorowo. Starszy programista poprawia coś w kodzie i nagle sypie mu się reszta.
Na oko testy są pisane błędnie lub robisz to na "odwal się".
Dobre testy to podstawa lub zamiennie, myślenie nad metodą 2h zamiast 10 minut.
Jak masz czas na takie rozmyślania to olej testy (jak zapewne robisz to teraz).

0

Unit testy - i tak - seniorow lapie biala goraczka - jesli nie ucza to nie ogarniaja jak tak banalnych rzeczy mozna nie kojarzyc (a im wydaje sie wiekszosc rzeczy za proste)

3

Nie, senior wie, że każdy może się pomylić, nie wiedzieć czegoś itp, sam też czasem czegoś nie wie.
Od tego są kod review i seniorzy też na nich dostają poprawki od innych seniorów, a czasem nawet juniorów. To jest naturalna sprawa.
Niefajne jest u Ciebie natomiast to, że kod nie jest reviewowany od razu. To że brakuje unit testów powinno też wyjść na code review i na jakichś sonarach. Więc to nie Ty masz problem tylko proces jest zły.

1

Zgadzam się z przedmówcą. Macie jakiś dziwny proces, bo czy te błędy wychodzą na produkcji?! Pomijając brak code review, to gdzie Wy macie jakichkolwiek testerów- nawet zwykłych klikaczy? Rolą juniora w pracy jest przede wszystkim się uczyć, ale wygląda na to, że nie masz najlepszych wzorców. W takiej sytuacji nadrabiaj netem i książkami. Dobre unit testy powinny obejmować wszystkie dozwolone przypadki użycia danej metody oraz wszystkie niedozwolone przypadki, jakie kiedykolwiek z jakichś powodów mogłyby mieć miejsce - objętościowo testów musi być dużo więcej, niż kodu, który testują. Przeczytaj sobie książki wujka Boba o tworzeniu czystego kodu, bo na tego seniora nie ma co liczyć - napisałeś, że "senior co jakiś czas sprawdza zadania po mnie" - przecież to rozbój w biały dzień! U mnie w zespole backendowym, w którym sam jestem głównym odpowiedzialnym za kod, choćby jedna linijka kodu nie może przejść na DEVa, jeśli ktoś nie klepnął mi Code Review oraz jeśli build jest zepsuty, co znaczy, że testy muszą być i muszą działać. Jeżeli nie masz w firmie dobrych praktyk, sam postaraj się o nie. Jeśli to janusze, dla których 500 driven development jest drogą do sukcesu, by dostarczać co i raz ficzery, poszukaj czegoś innego.

Popytaj o CI - Jenkins, Bamboo, Travis - cokolwiek, co odpali testy. Popytaj o unit testy - skoro Java to pewnie JUnit, Mockito itp. Nie stój w miejscu i nie czekaj aż senior znowu Ci wytknie błędy, tylko sam zrób krok w celu, aby pracować nad błędami. Uwierz mi, ale błędy będą zawsze. Od Ciebie zależy to, jak szybko one wyjdą - jak w trakcie CR- super. Jak na produkcji - sieka.

0

nie, nie tak źle to nie wygląda;]
pierwszy okres na stażu to zawsze po zrobieniu czegoś sprawdzał od razu i tłumaczył co robię źle, co byłoby lepsze itd.
teraz jest raczej coś w stylu zaufania. na produkcje to nie idzie.
mamy automaty co budują aplikacje - po pullu dostajemy wszyscy informacje czy na pewno wszystko się buduje itd ;)
testerów też mamy, ale ci dopiero na koncu sprawdzaja, potem zaś my poprawiamy
unit-testow nie mamy, nawet nie wiem co to :D
w kazdym razie sam staram się sprawdzac kazda funkcjonalnosc wysylajac dane do API
czasem jest po prostu tak, ze w jednym zadaniu jest nawet 20 funkcjonalności i niekiedy ta "ostatnia" wydawałaby sie nie miec wpływu na tą pierwsza (zazwyczaj najprostszą) i zapomniam sprawdzac, a potem cos nie działa :D (funkcjonalnosc jedynie, program nadal działa, a jak sie aplikacja nie buduje to przychodza i pałują D:D)

0

zamiast po pullu mialobyc po pushu ;)
ale moze poczytam o tych unit-testach - do tej pory to było napisanie kodu->debug->dane sie zapisały prawidłowo->super, a jak nie to zaś debug, zmiany w kodzie itd ;)

0
[babangida napisał(a)]:

w kazdym razie sam staram się sprawdzac kazda funkcjonalnosc wysylajac dane do API
czasem jest po prostu tak, ze w jednym zadaniu jest nawet 20 funkcjonalności i niekiedy ta "ostatnia" wydawałaby sie nie miec wpływu na tą pierwsza (zazwyczaj najprostszą) i zapomniam sprawdzac, a potem cos nie działa :D (funkcjonalnosc jedynie, program nadal działa, a jak sie aplikacja nie buduje to przychodza i pałują D:D)

A nie mozesz zautomatyzowac tego wysylania danych do API zeby nastepnym razem jakiegos przypadku nie pominac?

1

ale moze poczytam o tych unit-testach

Jak nie robisz, to wykazujesz się brakiem profesjonalizmu.

senior co jakis czas sprawdza zadania po mnie, no i...
zdarzaja sie zwrotki co jakis czas, nawet zadania z przed miesiąca - dwóch

Z kolei jeśli code review czy integracja z resztą aplikacji jest dopiero po miesiącu, dwóch, to senior (czy ogół zespołu) wykazuje się brakiem profesjonalizmu.
"co jakiś czas sprawdza", "zadania z przed miesiąca"... Szkoda, że nie sprzed roku xD

W porządnej firmie byłby jakiś code review jak najszybciej, i integracja też najszybciej (oczywiście wymóg testów, żeby wykryć, czy dana funkcjonalność działa jak trzeba).

Więc to, co powinieneś zrobić to poruszyć te sprawy na jakimś spotkaniu, u przełożonego, bo ty możesz być słaby technicznie - ale zespół widać nie lepszy, bo całkiem nieprofesjonalny (z tego co mówisz, to jakiś Janusz Soft).

teraz jest raczej coś w stylu zaufania. na produkcje to nie idzie.

Jak na produkcję to nie idzie, to raczej jest to brak zaufania ;)

unit-testow nie mamy, nawet nie wiem co to :D
...
troche siara, bo on to testuje i wywala mu na jakiejś głupocie - (...)
ale potem wprowadze zmiany do jakiś większych funkcjonalności, a te małe zaś przestaną działąć...

Wygląda jak "What could possibly go wrong" development ;)

ja to zawsze testuje,

no właśnie z tego co mówisz, to za bardzo nie testujesz.

czasem jest po prostu tak, ze w jednym zadaniu jest nawet 20 funkcjonalności
i niekiedy ta "ostatnia" wydawałaby sie nie miec wpływu na tą pierwsza (zazwyczaj najprostszą)
i zapomniam sprawdzac, a potem cos nie działa

Mam nadzieję, że nie będę zmuszony korzystać z żadnego serwisu, który robi wasza firma XD

0
babangida napisał(a):

czy wy jako seniorzy dostajecie białej gorączki przy sprawdzaniu zadań / kodu po juniorach i nagle coś się wywala : )?

Nie, ponieważ mamy unit testy, testy integracyjne, code review i... fail fast (przynajmniej w mitycznym wyidealizowanym miejscu pracy).
Jeśli błąd przeszedł przez wszystkie te etapy i został wykryty dopiero na produkcji to znaczy że zawiniły przede wszystkim te wcześniejsze etapy.
A jeśli ten etapy są w porządku (pokrywają wadliwy kod a błąd jest trudny do wychwycenia patrząc na kod) to znaczy że błąd jest jakimś przypadkiem brzegowym i jako junior mogłeś go przeoczyć.

W wychwyceniu błędów pomocne mogą być również:

  1. próbne odpalenia funkcjonalności i "zabawa" nią (klikasz to co Ci przyjdzie do głowy). Bywa że ludzie tego nie robią i zmieniają i commitują zmiany w nieużywanym kodzie.
  2. dobre IDE wyłapujące wszelkie nieścisłości (IDEA)
  3. kontrola statyczna kodu (jako juniorowi polecam również jako źródło do nauki) - PMD, FindBugs, Checkstyle

Musisz uważać również na to jakiego rodzaju błędy Ci ktoś zgłasza (najważniejsze najwyżej):

  • logiczne: np..zły warunek w if czy pętli, brak sprawdzenia null itd.
  • jakościowe: np. za długa funkcja (PMD), new Exception bez throw, catch bez kodu
  • stylistyczne: np. "tu bym zrobił osobną klasę typu Strategia bo pewnie w przyszłości się przyda to podmienić" albo "u nas się to robi inaczej"

Błędy stylistyczne po prostu przyjmujesz do wiadomości bo mogą to być "widzi misie" sprawdzającego a może ma rację - nie wiesz tego i mogą to być sprawy dyskusyjne. Możesz też pobawić się w detektywa - można np. sprawdzić czy recenzent sam takich błędów nie robi i wtedy ew. zapytać się go dlaczego gdzie indziej sam tak zrobił. Może jest jakaś ukryta dodatkowa reguła?

Błędy jakościowe po prostu poprawiasz i bierzesz pod uwagę na przyszłość.

Błędy logiczne nie powinieneś popełniać - patrz 1-3.

2
  1. A code review gdzie? Bo wygląda mi to tak jakby code review nie było.
  2. Unit testy!
  3. Moze sonar spięty z CI żebyś od razu widział jak coś potencjalnie jest z kodem nie tak?
1
vpiotr napisał(a):
babangida napisał(a):

czy wy jako seniorzy dostajecie białej gorączki przy sprawdzaniu zadań / kodu po juniorach i nagle coś się wywala : )?
Nie, ponieważ mamy unit testy, testy integracyjne, code review i... fail fast (przynajmniej w mitycznym wyidealizowanym miejscu pracy).

U nich tego nie ma bo nie miał ich kto tego nauczyć
> tutaj jest mniej wiecej podzial 3 juniorow, regular i senior
Struktura jak w janusz-soft-agencjareklamowa, ten jeden senior nazywany seniorem nie ma pojęcia jak powinna wyglądać praca

Podręcznikowy przykład na to, że samo 3+ lat doświadczenia nie czyni seniorem

1
babangida napisał(a):

senior co jakis czas sprawdza zadania po mnie, no i...
zdarzaja sie zwrotki co jakis czas, nawet zadania z przed miesiąca - dwóch
troche siara, bo on to testuje i wywala mu na jakiejś głupocie

No nie trochę, to bardzo wielka siara, jeśli senior testuje.

  • ja to zawsze testuje, ale potem wprowadze zmiany do jakiś większych funkcjonalności, a te małe zaś przestaną działąć...

Po to właśnie są testy, czego różni tokarze i dinozaury nie rozumieją. Nie dla jakiejś ideologii, nie dlatego, że to modne, nie dlatego, że wszyscy o tym mówią, tylko po to, aby móc wprowadzać zmiany.

czy to normalne ze robie czasem byki?

Każdy robi.

czy wy jako seniorzy dostajecie białej gorączki przy sprawdzaniu zadań / kodu po juniorach i nagle coś się wywala : )?

Ja nie mam takich doświadczeń, bo sprawdzam kod tylko po seniorach, ale głupie błędy raczej mnie śmieszą niż wkurzają.

0

Irytujące jest, jeśli ktoś robi te same błędy wielokrotnie.

O sam fakt, że junior je robi, trudno mieć pretensje - dlatego to senior jest seniorem i ma płacone więcej ciuciu, a nie odwrotnie.

Jeżeli takie błędy - których należy się wręcz spodziewać - mają poważny wpływ na pisany soft i na aspekt biznesowy, to znaczy, że coś nie tak jest z systemem pracy. Być może są wyłapywane zbyt późno? Podstawowe dobre praktyki, które temu przeciwdziałają, podali już w tym wątku poprzednicy: code review (zwłaszcza częste i wczesne), testy jednostkowe itd.

Stworzenie sprawnego systemu pracy nie jest zadaniem, które ma sobie sam wykonać junior. Od tego jest firma jako organizacja i zasób doświadczenia, by go do takiego produktywnego systemu przyuczyć i wciągnąć.

1 użytkowników online, w tym zalogowanych: 0, gości: 1