Standardy kodu, szybka zmiana pracy

Cześć,

w lipcu podjąłem praktyki w firmie X. Jakiś czas temu zaoferowano mi pozostanie w firmie na dłużej. Ofertę tymczasowo przyjąłem.

Noszę się jednak z zamiarem odejścia. Zanim podejmę decyzję, muszę znaleźć oczywiście inną pracę, ale najpierw kilka pytań do Was:

1. Czy ktoś z Was miał w swojej karierze podobną sytuację? Podobną == rezygnacja z pracy po 3 miesiącach. Podejrzewam, że nie zachęci to specjalnie przyszłego pracodawcy, bo będę wyglądał na osobę skaczącą po firmach. Jaką postawę przyjęliście podczas kolejnej obrony - w jaki sposób odpowiedzieliście na pytanie o powód tak szybkiej rezygnacji?
2. W celu rozeznania terenu:

• jak wyglądają standardy pracy w Waszej obecnej firmie? Obowiązkowy code review przed commitem? Jaki stopień pokrycia kodu testami? A może macie team testerów/QA?
• czy sporo legacy code'u, brak unit testów, code review i praktycznie jakiejkolwiek kontroli nad tym, co robicie jest wg Was wystarczającym powodem do odejścia? Do tego dochodzi dosyć "nietypowy" stack technologiczny.

Ach, kilka szczegółów:
Java, Kraków

Dzięki z góry za jakieś sensowne wypowiedzi.
Pozdrawiam

Z twojego posta wnioskuję, że nie skaczesz po firmach i nie jest to firma któraś z kolei. Jeśli nie podoba Ci się w obecnej firmie, to jak najbardziej wskazane jest abyś poszukiwał innego miejsca zatrudnienia, tym bardziej że zaczynasz karierę. Poza tym czym ty się martwisz? - bezpieczny etacik masz zaklepany, bo zaproponowali Ci przedłużenie. Na chwilę obecną masz wybór:

• zostanie w firmie i szukanie zatrudnienia
• odejście z firmy i szukanie zatrudnienia

według mnie, najbardziej opłacalnym wyborem jest opcja nr 1. Dlatego nie noś się z zamiarem odejścia dopóki nie będziesz miał zaklepanego etatu. Pracuj jak pracujesz, chodź po rozmowach jak uda Ci się wyhaczyć lepszą oferte, to składasz wypowiedzenie i adios.
Co do standardów wytwarzania oprogramowana - wszystko zależy od konkretnej firmy. Kryteria masz. Według mnie robienie code review każdego commita to lekka przesada. A aplikacji nie da się pokryć w 100% testami. Co nie oznacza, że firmy które w ogóle nie wykorzystują TDD, BDD, wzorców projektowych i zalecanych praktyk są zajebiste. Wszystko z rozwagą.

Ja wiem, że nie otestuję 100% kodu i że pewnie code review każdego commita to przesada. Dlatego pytam, jak pod takim względem to wygląda u Was. Żeby nagle nie okazało się, że rzucam robotę z jakiegoś wydumanego powodu, podczas gdy 90% firm na rynku jest taka sama.

No to z jakich pobudek chcesz rzucić tą firmę. Jak mniemam - chodzi Ci o rozwój?. Skoro znasz standardy i czujesz że w obecnej firmie cofasz się w rozwoju, to odpowiedź na swoje pytanie masz. Sam kiedyś miałem takie rozterki, ale jeszcze gorsze bo nawet nie używaliśmy systemu kontroli wersji. Żałuję ? - nie. Zarobki ciut spadły, ale moja sytuacja rozwojowa obróciła się o 180 stopni. Przepracowałem w tej firmie aż 4 miesiące, bo tak na prawdę było to cofanie się w rozwoju...

• czy sporo legacy code'u, brak unit testów, code review i praktycznie jakiejkolwiek kontroli nad tym, co robicie jest wg Was wystarczającym powodem do odejścia? Do tego dochodzi dosyć "nietypowy" stack technologiczny.

Tak.

U mnie (stary kod):

• Każdy kod który zmienia logikę wymaga code review i dodania testów (albo dodania taska z planem dodania testów i podanie jego numeru w CR) - ludzie bardzo niechętnie przyjmują zmianę logiki bez uzasadnienia - nikomu nie chce się analizować, a nikt nie chce zepsuć działającego kodu,
• Każdy kod który zmeinia coś w buildzie wymaga code review (te są z reguły dużo luźniejsze i są bardziej informacyjne)
• Code review testów jest stosunkowo luźny jako, że ten kod nie idzie na produkcję.

Jak robisz nowy projekt to nie musisz co prawda wysyłać review dopóki nie skończysz, ale dużo lepiej wyjdziesz na tym jeśli to zrobisz, bo nim dalej się posuniesz z kodem tym więcej ewentualnych zmian. Najlepiej dodawać nowe featury po kolei.

czy sporo legacy code'u
Chcesz powiedzieć że co roku trzeba pisać wszystko od nowa nawet jeśli działa, bo to już jest legacy code?

Nie.
Mam na myśli projekty napisane X lat temu, które trzeba utrzymywać. Takie z "ośmiotysięcznikami i smutnymi metodami po kilkaset linii".

Rozumiem przytyk. Ja nie z tych, którzy uważają, że każdy kod napisany dalej niż przed tygodniem, to legacy code. Również nie jestem z tych, którzy uważają, że piszą zajebisty kod. Wręcz przeciwnie - pewnie sam sadzę kwiatki do repozytorium.

Różnica jest taka, że dopiero co zacząłem karierę i jeszcze mam ochotę coś z tym zrobić, oni nie bardzo.

U mnie nie da sie nic wcommitowac bez review, wiec nawet zmiana kropki w komentarzu musi przejsc review.

Jak wyglądają standardy pracy w Waszej obecnej firmie?

U nas staramy się robić Code Review każdego Merge Requesta/Pull Requesta, który może zawierać 1 commit lub więcej. Testy staramy się pisać, ale nie jest idealnie (na pewno nie ma 100% pokrycia - jest znacznie mniej). Nie było tak od samego początku, tylko od pewnego momentu. W każdym teamie jest przynajmniej 1 lub 2 QA.
Obecnie jest mało legacy kodu, bo jest nowy projekt, ale legacy kod się zdarzał w poprzednich projektach i zazwyczaj jest w pewnym momencie nieunikniony (np. dla nowej osoby dołączającej do projektu, kod, przed którym siądzie już będzie legacy)

Ja ani Java ani Kraków, ale tak ogólnie:

juniorJava napisał(a):

Jaką postawę przyjęliście podczas kolejnej obrony - w jaki sposób odpowiedzieliście na pytanie o powód tak szybkiej rezygnacji?

Chociażby brak warunków do pracy (hałas, stary sprzęt) albo niezgodność zadań z umową (np. tnie się grafikę zamiast programować).

• jak wyglądają standardy pracy w Waszej obecnej firmie? Obowiązkowy code review przed commitem? Jaki stopień pokrycia kodu testami? A może macie team testerów/QA?

Jak najbardziej code review przed commitem do brancha długotrwałego.
Testy automatyczne są pupochronem programisty i pozwalają bezpiecznie refaktoryzować. Ale pod tym, że dana funkcja działa jako całość, i tak musi się podpisać żywy tester.

• czy sporo legacy code'u, brak unit testów, code review i praktycznie jakiejkolwiek kontroli nad tym, co robicie jest wg Was wystarczającym powodem do odejścia? Do tego dochodzi dosyć "nietypowy" stack technologiczny.

Legacy code trzeba refaktoryzować, a unit testy dopisywać, wtedy te dwa problemy się same rozwiązują. I każdy stack technologiczny jest nietypowy, bo nigdzie nie ma dwóch takich samych. :)
Co to znaczy "brak jakiejkolwiek kontroli"?

Legacy code trzeba refaktoryzować, a unit testy dopisywać, wtedy te dwa problemy się same rozwiązują.

Testy chciałem pisać. Pisałem nawet. Może nie do starego kodu, ale do nowego. Nie zostało to najlepiej przyjęte ;)

Co to znaczy "brak jakiejkolwiek kontroli"?

Mniej więcej tyle, że jak puszczę krzaki do repo, to dostanę po głowie dopiero wtedy, gdy ktoś się na nie natknie ;)

Była ostatnio dyskusja o tym, kiedy można odejść, żeby nie wyglądało to na skakanie po firmach, część osób twierdziło, że minimum które się broni to pół roku. Ja byłem w takiej sytuacji, że pracowałem od początku lipca i wiedziałem już od pierwszego dnia, że ta firma to pomyłka. Wpisałem to w CV (bo z drugiej strony było w tym coś, co w CV mi się przydało), po dwóch miesiącach zacząłem szukać pracy, zaprosili mnie na rozmowę do firmy do której chciałem, tam powiedziałem dlaczego tak szybko zmieniam i tyle. Jeżeli masz logiczne wytłumaczenie, to na pewno Cię zrozumieją.