Słabo prowadzony projekt, brak dokumentacji, inne grzechy. Czy zmieniać?

Cześć!

Jakiś czas temu (na początku roku) zmieniłem miejsce pracy i wszystko było ok przez kilka pierwszych miesięcy. Firma fajna, ludzie fajni, projekt prowadzony nawet sensownie, ogarnięty zespół brak nacisków i spokojna praca bez pośpiechu.

Jednak po kilku miesiącach przeniesiono mnie do innego projektu, gdzie trafiłem praktycznie poza firmę i pracuję bezpośrednio dla klienta z zagranicy.

Dużo się zmieniło wtedy dla mnie na minus. Projekt jest bardzo słabo prowadzony. Sprinty planowane są bez żadnego głębszego zastanowienia.
Ot dzień przed rozpoczęciem sprintu maanagerka (nawet spoko kobieta) albo inny ktoś inny zakłada na szybko taski i wymyśla jakie funkcjonalności trzeba zaimplementować w aplikacji.
Później pokazuje mi mniej więcej co chce opisując to dwoma zdaniami wypowiedzianymi z hinduskim akcentem i tyle. Używając przy tym w cholerę branżowego języka i pojęć z dziedziny biznesowej firmy, których przeciętny programista nie zna. Problem jest taki że domena z jaką pracujemy nie jest dla mnie w ogóle zrozumiała. Generalnie obróbka serii danych które nic nie mówią normalnemu człowiekowi.

Cały projekt nie ma nawet zrąbka dokumentacji.
Taski, które zakładają osoby odpowiedzialne za to nie posiadają żadnych specyfikacji ani grama wymagań czy opisu. Ticket w asanie to tylko numer i nazwa. Ja mam się domyślać wszystkiego jak dana funkcjonalność ma wyglądać - dla nich to może i jest oczywiste bo siedzą w firmie kilka lat i wiedzą co tam robią. Ja hooya rozumiem po samym tytule a jak dopytuję to też nie jest wcale prościej bo jak zaczną rzucać branżowym językiem to też nie wiem często o co kaman.
W mojej poprzedniej mojej pracy jakby tak taski wyglądały to nasz team lider by w ogóle nie dopuścił ich do sprintu ani nawet nie pozwoliłby przystąpić do ich wyceny. A tutaj to jest normalne.

W projekcie nie ma w ogóle sensownych testerów, i na coś co jest taką jakby produkcją (jacyś klepacze wprowadzają tam dane) trafiają feature'y których nikt nie testował nigdy.
Dodatkowo problemy są wieczne ze stabilnością środowiska deweloperskeigo, bo jedyny dev który w projekcie jest od początku wszystko robił pod siebie, jak chciał i u niego tylko działa jak należy.

Jestem w projekcie już jakieś 3 miesiące i moje pytanie to czy siedzieć w tym projekcie dłużej i czekać aż ogarnę o co chodzi czy ewakułować się? Nie wiem czy to we mnie jest problem że nie rozumiem często co mam robić, czy to przez ten projekt jest w ogóle nie przygotowany. Obstawiam to drugie.
Ja raczej ogarniam jak już zrozumiem co mam zrobić, bo na daily czy sprint review ja zawsze prezentuję najwięcej co zrobiłem i co dowiozłem.
Reszta ludzi to mam wrażenie, że niewiele robi. Może mam takie odczucie dlatego, że na daily mamy nie tylko devów ale i jakichś ludzi od baz danych i innych którzy nie wiem nawet co robią bo każdego dnia mówią dokładnie to samo co poprzedniego.

Moje pytanie czy często znajdujecie się w projektach które są słabo prowadzone? w których nie ma żadnej dokumentacji, zapytać też nie bardzo jest się kogo bo dev z którym pracuję siedzi w projektach w tej firmie ze 20 lat, wszystko robił po swojemu zna domenę i nie potrafi zrozumieć że domena biznesowa projektu nie jest tak oczywista - zwłaszcza jak nie ma nawet strony dokumentacji?

Nie wiem czy nie powinienem zacisnąć pośladów i probować żyć z tym czy szukać zmiany?

Dodatkowo bardzo nie podoba mi się to że zostałem wysłany do klienta mimo, że jak się zatrudniałem to firma przekonywała mnie ze nie wysyłają ludzi do klientów tylko pracujemy w zespołach wewnątrz firmy nad projektami dla klientów.

W projekcie nie ma w ogóle sensownych testerów, i na coś co jest taką jakby produkcją (jacyś klepacze wprowadzają tam dane) trafiają feature'y których nikt nie testował nigdy.

Nie ma testów automatycznych ani manualnych? Czyli nikt tego nawet nie przeklikuje, co robicie? To lepiej się ewakuować, dopóki jeszcze są szalupy ratunkowe.

Moje pytanie czy często znajdujecie się w projektach które są słabo prowadzone?

Większość projektów jest słabo prowadzona, jednak zadałbym inne pytanie - czy ludzie, którzy są w tym projekcie zdają sobie sprawę z tego, że projekt ma pewne trudności i czy starają się jakoś polepszać, czy może kładą lachę.

np. ten brak testów. Czy to jest w stylu słabo, że nie mamy testów w starym kodzie, ale nowy kod starajmy się testować, czy może po co testy, nie ma czasu albo przecież działa.

albo: problemy są wieczne ze stabilnością środowiska deweloperskeigo, bo jedyny dev który w projekcie jest od początku wszystko robił pod siebie, jak chciał i u niego tylko działa jak należy. - czy widzisz szanse na rozwiązanie tego w jakiś sposób (np. jakbyś sam naniósł potrzebne zmiany albo nacisnął na tego deva, żeby to ulepszył), czy może jednak spotykasz się z betonem i niezrozumieniem, że ci to w ogóle przeszkadza?

Cały projekt nie ma nawet zrąbka dokumentacji. - albo czy jeślibyś chciał się zabrać za pisanie dokumentacji (albo namawiał innych), to czy by twoje działania spotkały się ze zrozumieniem, czy nie, bo po co.

Ja raczej ogarniam jak już zrozumiem co mam zrobić, bo na daily czy sprint review ja zawsze prezentuję najwięcej co zrobiłem i co dowiozłem.
Reszta ludzi to mam wrażenie, że niewiele robi

To akurat dobry znak, bo to znaczy, że nie masz gorszej wydajności od reszty, a nawet lepszą. Projekt jest beznadziejnie prowadzony, ale ludzie to akceptują i kładą lachę. Czyli wygląda na to, że jest to dobry projekt, jak chcesz udawać, że pracujesz, brać kasę i mieć wyje*ane (bo jak rozumiem, taka jest motywacja innych ludzi w tym projekcie). Z drugiej strony jest to mało rozwojowe i moim zdaniem lepiej poszukać czegoś lepszego, gdzie będą poważniej i profesjonalniej podchodzić do procesu tworzenia software'u.

Zgłaszasz się do swojej firmy, że chcesz zmienić projekt, podajesz argumenty czemu w tym, że nie takie było zapewnienie gdy się zatrudniałeś. Jak nie podziała to ewakuacja.

Jeżeli u ciebie zgorzknienie dosięgło już takiego poziomu, że chciało ci się wysmarować ten post, to z własnego doświadczenia powiem, że nie będzie lepiej.

• jak twoja obecna stawka wygląda w stosunku do rynku?
• dlaczego przeniesiono cię do innego projektu? Za karę?
• czy jest szansa, że przejmiesz kawałek systemu na własność i zaprowadzisz w nim porządek?

Managerka wymyśla taski?

Jezeli pracujesz w projekcie, ktory jest zle prowadzony pod wzgledem developerskim (brak review, testow, itd) to masz 2 mozliwosci)

a) Pod warunkiem, ze posiadasz wymagane umiejetnosci mozesz wykazywac sie aktywna postawa i udzielac w tematach developerskich, tlumaczyc ludziom co zle robia, blokowac ich na review itd.
b) Siedz sobie te 8 godzin, gnij w srodku i zarabiaj kase
c) Zmien projekt/robote

Opcja A moze byc ryzykowna, bo moze sie okazac ze robisz to wszystko "za frajer", a z drugiej strony moze manager/ team leader zauwazy Twoje zaangazowanie i na przestrzeni 6-12 miesiecy dostaniesz duuuza podwyzke i awans.

Ja mam bardzo proste podejście, Nie istnieją projekty idealne, ale mam jakieś tam wyobrażenie jak projekt idealny dla mnie powinien wyglądać. Jeżeli nie widzę możliwości zmierzania w kierunku tego ideału, czyli "jest ..., ale stabilnie" to rezygnuję. Istnieją projektu, z którymi nic nie da się zrobić, bo ich historia, układy interpersonalne tak betonują sytuację, że każda próba zmiany, nawet prawie nieistotnej zmienia się w wojnę, ale to jest moim zdaniem mniejszość.

Seken napisał(a):

z drugiej strony moze manager/ team leader zauwazy Twoje zaangazowanie i na przestrzeni 6-12 miesiecy dostaniesz duuuza podwyzke i awans.

Nie. Team leader zauważy, że nowa osoba robi jakieś problemy, a wcześniej problemów nie było. Kolega co najwyżej dostanie kopa. Gdyby team leader był zdolny do wyciągnięcia takich wniosków jak piszesz, to projekt nie byłby tak właśnie prowadzony.

Rozwiazanie - aplikujesz na 5 ogloszen z czego masz co najmniej 3 oferty na koniec i wybierasz najlepsza.

Chyba wszędzie jest syf większy lub mniejszy. Najważniejsze jest by pracować z ludźmi, którym się chce, którzy chcą nad tym syfem zapanować. Zgłaszaj wszystkie pomysły na usprawnienia.

Podstawowe pytanie jest takie - czy ci to tobie odpowiada? Ja przykładowo lubię taki średni chaos w projekcie, bo wtedy można uczyć się rzeczy, których w dobrze poprowadzonym projekcie byś nie miał okazji spróbować. Z drugiej strony rozumiem ludzi, którym nie podoba się to, że nie mogą sobie rozplanować tygodnia w pracy - bo byłem i w takich projektach, w których dało się łatwo i fajnie wszystko ułożyć.

@wartek01: Dokładnie tak. Ja nie mam najmniejszego problemu z tym, że np. wymagania się zmieniają, że tydzień temu ważne było A, a teraz ważniejsze jest B, albo trzeba postawić jakiś serwer, a nie mam o tym pojęcia. Jeżeli tylko zadanie ma sens, jestem przekonany, że ono jest potrzebne to luz. Wkurzają mnie za to jakieś deadline'y z d...y, scrumowa wyrównywaczka do najniższego możliwego poziomu, zadania, które ktoś chce mieć zrobione, ale nie ma pojęcia co one mają robić, albo decyzyjny bezwład, który powoduje, że zadanie sobie czeka miesiąc na decyzję czy jest pilne, a później trzeba je zrobić na wczoraj. Jak jeszcze powodem jest jakiś absurd, w stylu "bo już zaplanowaliśmy sprint", to potrafi ze mnie wyjść ta strona osobowości, z której nie jestem dumny.

Nie wiem skąd u niektórych taki ból D o to, jak projekt jest prowadzony. Czy to twój projekt? Czy to ty odpowiadasz głową za niepowodzenia? Przychodzisz do pracy, robisz swoje, wracasz do domu. Jeżeli z powodu złego zarządzania projekt upadnie, to PM oberwie. Jeśli nie dostaniesz jasno wyznaczonego zadania, to go najwyżej nie wykonasz. Jak zechcą zwalić na ciebie to mówisz fuck you, rzucasz papier i idziesz do innej firmy, ofert jest pełno.

Często obserwuję nadmiar osobistego zaangażowania, tym większego im bardziej jesteś dymany. Coś jak syndrom sztokholmski. To nie twoja w tym głowa, żeby wszystko prawidłowo zorganizować.

@gajusz800: Zasadniczo też tak uważam. Nikt dzisiaj nie pamięta, ile wysiłku i serca włożyłem na projekty 10 lat temu. Jedyne, co z tego realnie dzisiaj mam, to marna kasa i wpis w CV.
Ale ciężko przełamać naturę. Np jak spojrzysz na piramidę Masłowa, to potrzeba uznania i potrzeba samorealizacji jest czymś, co mnie boli w roli klepacza kodu w nieoptymalnym projekcie, gdzie mój szef powinien już dawno temu wylecieć za niekompetencję i złe decyzje. Jak masz jakiś hack, jak to obejść, to chętnie posłucham, bo akurat mam kryzys.

gajusz800 napisał(a):

Nie wiem skąd u niektórych taki ból D o to, jak projekt jest prowadzony. Czy to twój projekt? Czy to ty odpowiadasz głową za niepowodzenia? Przychodzisz do pracy, robisz swoje, wracasz do domu. Jeżeli z powodu złego zarządzania projekt upadnie, to PM oberwie. Jeśli nie dostaniesz jasno wyznaczonego zadania, to go najwyżej nie wykonasz. Jak zechcą zwalić na ciebie to mówisz fuck you, rzucasz papier i idziesz do innej firmy, ofert jest pełno.

Często obserwuję nadmiar osobistego zaangażowania, tym większego im bardziej jesteś dymany. Coś jak syndrom sztokholmski. To nie twoja w tym głowa, żeby wszystko prawidłowo zorganizować.

To co proponujesz to całkiem rozsądne. Pamiętaj tylko że są ludzie którzy lubią pracować mądrze oraz wykonywać swoją pracę w jak najbardziej kompetentny sposób. Kiedy w otoczeniu widać brak nacisku na jakość tego co się dostarcza (bez znaczenia co to jest) to taka osoba po prostu cierpi.
Niektórym potrzeba czasu żeby dojść do etapu bezstresowego. Sam jestem chyba przykładem, moja skóra zrobiła się dużo grubsza ale i tak kiedy czasem rozejrzę się wokół to włos na głowie się jeży.

imo wczuwasz sie za bardzo a to tylko praca

@kimikini: wiekszość z nas lubi programowanie i to też nasze hobby więc sorry ale takie firmy obrzydzają to więc ewakuacja to naturalna sprawa. Jeśli programujesz tylko dla hajsu to nie zrozumiesz.

Na dwoje babka wróżyła

1. można się oburzyć i zmienić projekt/firmę/zawód. Dobre rozwiązanie jak jest sie młodszym i ma się dużo czasu na rekrutacje
2. można próbować naprawiać świat. Im team mniejszy i jest się starszy to tym łatwiej
3. moża też mieć wyj*** "byle do emerytury" lub "byle leciały dupogodziny"

do tej pory testowałem podejście 1. Teraz spróbuje 2. Ale jak widzę metody na 100 lini które mi się nie mieszczą to mnie trzepie. Albo jak widzę metody kopiuj wklej. 11 lat pracuję a projekty copy-paste mają się dobrze

ehhhhh napisał(a):

@kimikini: wiekszość z nas lubi programowanie i to też nasze hobby więc sorry ale takie firmy obrzydzają to więc ewakuacja to naturalna sprawa. Jeśli programujesz tylko dla hajsu to nie zrozumiesz.

Dokladnie, wiele osob mowi zeby sie niczym nie przejmowac, a najlepiej to miec wszystko w dupie. A ja takim osobom szczerze wspolczuje, bo w pracy spedzamy 1/3 doby (mozna powiedziec, ze 1/2 doby "uzytkowej"). Strasznie to smutne byc ambiwalentnym przez taka kupe czasu.

KamilAdam napisał(a):

Ale jak widzę metody na 100 lini które mi się nie mieszczą to mnie trzepie. Albo jak widzę metody kopiuj wklej. 11 lat pracuję a projekty copy-paste mają się dobrze

Sto linii to całkiem niewiele. MIałem nieszczęście pracować w projekcie gdzie metody kontrolerów miały po kilkaset. Do dziś pamiętam minę manadżera kiedy zaproponowałem mu wezwanie egzorcysty.
Dobry chłop był ale miał nieszczęście jeśli chodzi o dobór ludzie. Poza mną oczywiście :D

Wg mnie wszystko zależy. Metoda może mieć i z 500 liniijek i być do ogarnięcia bardziej niż 50 metod po 10 linijek, gdzie każda metoda korzysta z innej metody.

Załóżmy, że w pierwszym przypadku mielibysmy coś takiego:

function foo() {
    switch (a) {
       case option1: {
           // ....
           break;
       }
       case option2: {
          //....
          break;
       }
       //.....
    }
}

i w zasadzie na jedno kopyto. Nawet jakbyśmy mieli z 500 linijek, dalej byłoby w jakiś sposób czytelne.

W drugiej sytuacji powiedzmy, że mielibyśmy coś takiego:

function a() {
  g();
  d();
  if (m()) { n(); }
  return {foo: c(b(g()};
}
async function b() {
  await g();
  if (cond) {
      a();
  }
}
async function c() {
  if (g()) {
      await e();
  } else {
     if (d()) {
        r().forEach(d());
     }
  }
  //...
}
function d() {
  if (g() || c(b(z()) { 
      return h();
  }
}

// i tak dalej przez 500 linijek

Tutaj mimo, że funkcje są małe, to żeby dojść, która funkcja od której zależy trzeba byłoby się natrudzić mentalnie (albo użyć narzędzi typu debugger czy jakiejś statycznej analizy kodu).

Więc o ile pierwszy przypadek to dużo kodu z prostą logiką (zakładając, że poszczególne gałęzie case: byłyby faktycznie proste), to ten drugi przypadek to w zasadzie zwykły spaghetti kod.

Tak więc wielkość funkcji nie musi jeszcze świadczyć o czytelności. Owszem, bardzo często świadczy i można by dobrać inne przykłady, które pokazywałyby duże funkcje trudne w zrozumieniu i małe funkcje połączone w czysty kod. Tym niemniej nie jest tak, że małe funkcje to zawsze dobro, a duże funkcje to zawsze zło.

To już bym wolał:

function foo() {
    switch (a) {
       case option1: foo1();
           // ....
           break;
       case option2: foo2();
          break;
       //.....
    }
}

@LukeJL: Nie wiem jak metoda na 500 linii może być czytelna. Pewnie tak samo jak spotkane kiedyś znalezisko z sonara, "cognitive complexity 15000 allowed 7" załatane //nosonar it would be unclear if we split it.

Zresztą kiepski kod, to rzecz z którą można żyć. Gorzej, jak z jakiegoś powodu "nie da się go zmienić", nieważne czy powodem jest brak umiejętności technicznych, czy brak czasu, bo są jakieś rzekomo ważne powody biznesowe.

LukeJL napisał(a):

Wg mnie wszystko zależy. Metoda może mieć i z 500 liniijek i być do ogarnięcia bardziej niż 50 metod po 10 linijek, gdzie każda metoda korzysta z innej metody.

Załóżmy, że w pierwszym przypadku mielibysmy coś takiego:

function foo() {
    switch (a) {
       case option1: {
           // ....
           break;
       }
       case option2: {
          //....
          break;
       }
       //.....
    }
}

Dobra przypomniało mi się. Jest na to oczywiście wzorzec projektowy: Łańcuch zobowiązań. W Scali Łańcuch Zobowiązań można łątwo budować z PartialFunction (nazwa jest totalnie d'piata, bo partial function w programowaniu funkcyjnym oznacza zupełnie co innego XD)

val sample = 1 to 10
def isEven(n: Int) = n % 2 == 0
val eveningNews: PartialFunction[Int, String] = {
  case x if isEven(x) => s"$x is even"
}

val oddlyEnough: PartialFunction[Int, String] = {
  case x if !isEven(x) => s"$x is odd"
}

// PartialFunction to interfejs z dwoma metodami
// Proszę sobie wyobrazić że implementacji PartialFunction jest 2k a nie 2 sztuki
val pf = eveningNews orElse oddlyEnough
val numbers = sample.map(pf)

numbers.map(println)

UPDATE z wyjaśnieniem składni Scali (żeby nie robić jeszcze większego offtopu)

PartialFunction to składniowo pojedyncza linia z pattern matchingu, ale faktycznie to obiekt z dwoma metodami: predykatem sprawdzającym isDefinedAt i faktyczną funkcją do wykonania czyli metodą apply

val eveningNews: PartialFunction[Int, String] = {
  case x if isEven(x) => s"$x is even"
}

val oddlyEnough: PartialFunction[Int, String] = {
  case x if !isEven(x) => s"$x is odd"
}

Jest odpowiednikiem

val eveningNews = new PartialFunction[Int, String]() {
    def isDefinedAt(x: Int) = isEven(x)
    def apply(x: Int) = s"$x is even"
}

val oddlyEnough = new PartialFunction[Int, String]() {
    def isDefinedAt(x: Int) = !isEven(x)
    def apply(x: Int) = s"$x is odd"
}

linia

val pf = eveningNews orElse oddlyEnough

składa dwa PartialFunction w jeden i teraz pf jest odpowiednikiem

val pf: PartialFunction[Int, String] = (x0 => x0 match {
    case x if isEven(x) => s"$x is even"
    case x if !isEven(x) => s"$x is odd"
})

można by też zapisać

val pf: PartialFunction[Int, String] = (x => x match {
    case _ if isEven(x) => s"$x is even"
    case _ if !isEven(x) => s"$x is odd"
})

Metoda na 500 linii to już sporo imo, ale tak na 100-200 z perspektywy c++ to już w sumie spoko. (Pewnie w pythonie będzie mniej) Osobiście wolę większe funkcje niż tworzenie ogromnego call stacka przez którego ciężko się potem przeklikuje.

Bywaly metody i po kilka tysiecy liniii... I czlowiek od razu wiedzial ze dzien ma juz z glowy zanim rozkmini co tam siedzi...
@KamilAdam: glowna sila w robieniu wielu metod to jest to ze mozesz czytac kod jak ksiazke. Nie musisz sie skupiac na szczegole tylko zbudowac sobie obraz. Jak mam metode na tysiac linii to zapewne bedzie tam wszystko wrzucone bardzo niskopoziomowo. Zamiast rozmyslac co robi te 50linii wolalbym metode ktora ma jakas nazwe i od razu po jej przeczutaniu w kilka sekund jestem zorientowany. Ogolnie staram sie zawsze wydzielac metody przy pomocy IDE jak analizuje jakies bugi w takim kodzie. Jak kazdy w teamie podlapie bo widzi ze sie to przydaje to szybko da sie poprawiac kod szczegolnie ze 80% przypadkow zaglada sie do 20% kodu :D

A co do autora to ciezko powiedziec co lubisz i na co masz sily. Ja tam np nie lubie greenfield i mnie medzy praca w nim... a wszyscy to tak zachwalaja...

@Ziemiak: nie da się tego generalizować. Czasem kod jest tak podzielony że przez skakanie po 50 plikach by zbudować sobie obraz traci się tak samo dużo czasu albo i więcej niż jakby siedziało to wszystko jako jedna metoda.

Ja bym zgłosił się do Twojego przelozonego z kontraktorni zeby wyciagneli Cie z tego projektu i dali do czegos normalnego. A jesli to nie pomoze to wtedy uciekac stamtąd całkowicie. Szkoda życia i zdrowia na takie coś

Jeszcze do oftopu czemu długie funkcje/metody są złe. Właśnie musiałem cosiałem dodać jeden waunek do metody na 200 linii. Dosłownie jedną linijkę. Ale zmieniło to poziom wcięć i teraz mam 200 linii zmian XD