[Jacob]

Jak sobie radzicie z #!$%@? projektami w których nic nie działa i są wypełnione po brzegi długiem tech.?
#programowanie

[Papasanbaba]

@Jacob: Zazwyczaj przebudowa nie wchodzi w grę bo za drogo także doklejam swój kod jak placki gówna do asfaltu na wsi w letni dzień i póki jakoś działa to tak zostawiam. ( ͡° ͜ʖ ͡°)

[Jacob]

@Papasanbaba: Tak to jest wyjście które jak kula śnieżna czeka tylko na #!$%@?ęcie w kolejnym zadaniu które może zahaczać o to poprzednio ulepione i tak z dnia na dzień.

[Papasanbaba]

@Jacob: I tylko mieć nadzieje że nie jebnie akurat jak ty przy tym siedzisz. No czasem tak jest i nic nie zrobisz.

[Jacob]

@Papasanbaba: Damn doszliśmy myślowo do miejsca w którym właśnie jestem.

[MilionoweMultikonto]

@Jacob: jakimi testami masz pokryty ten projekt?

[Jacob]

@MilionoweMultikonto: Główna backendowa apka wystawiająca api jest pokryta jednostkowymi i integracyjnymi "jako tako" (czasem bezsensownymi) do tego uzależnienie od wielu zewnętrznych api, często wątpliwej jakości. Pretenduje do długoletnio rozwijanego highendowego produktu ale pod maską niezarabiające mvp. Rzeczy oczywiste które powinny działać nie działają albo nigdy nie były zakodowane.

[rzuf22]

@Jacob: ja zabudowałem stary #!$%@? kod pseudofasadą i nowy pisałem już normalnie. Jak coś trzeba było fixnąć w starym kodzie to albo szybki workaround (dokładając gówna do kodu), albo przepisywałem tą część na nowo (niestety nie zawsze się tak dało, bo czasami była to mocno rozbudowana część i człowiek nie dostawał czasu na nią). Takie już uroki legacy kodu...

[januszgorszyciel]

@Jacob: Na start jak największe pokrycie sensownymi testami które robią to co jest faktycznie potrzebne i przy okazji dokumentują co tu się odjaniepawla. Następny krok to stopniowy refactor tam gdzie masz wprowadzić zmiany/nowe funkcjonalności. Taski szacujesz tak, żeby wewnątrzy był czas na refactor. I po jakimś czasie można wyjść na prostą :)

[januszgorszyciel]

@Jacob: Dodam tylko, że prawie nigdy nie ma opcji na przepisanie czegoś od początku. Zazwyczaj gdy przedstawia się to w ten sposób, że Story zajmie 30/50% więcej ale w przyszłości będzie łatwiej wprowadzić jakieś zmiany jest o wiele łatwiejsze do przełknięcia dla właścicieli projektu/PM'a gdyż nadal widzą progres.

[Jacob]

@rzuf22: @januszgorszyciel:
Już odpowiadam. Nie da się, nie ma na to czasu, pchane są czasochłonne ficzery lub fixy rzeczy istniejących. Pokrycie tego testami raczej nie wchodzi w grę od strony biznesowo/budżetowej. Ale nie to jest clue.
Moje pytanie bardziej miało na celu dowiedzieć się co robicie jak już macie dość takiego projektu w którym każdy dzień to fuckup.

[januszgorszyciel]

@Jacob: No to przypał, zostaje tylko jak najszybsza ewakuacja niestety.

[rzuf22]

co robicie jak już macie dość takiego projektu

@Jacob: idę do menago i mówię, że chce zmienić projekt. Jakby mi odpowiedział, że nie da się to szukam innej pracy. Osobiście takiej sytuacji nie miałem, bo albo mi zmienili projekt, albo skusili konkurencyjną stawką. W świecie IT jest tyle możliwości, że czasami ciężko wybrać, bo tyle tego.

[Jacob]

@januszgorszyciel: doszedłem do podobnego wniosku
@rzuf22: również tak zrobiłem i zgadzam się z tymi możliwościami w IT.
Pytałem was bo chciałem poznać inny punkt widzenia a miałem wrażenie, że może powinno się zacisnąć zęby i robić za wszelką cenę jak w jakimś kołchozie

Dzięki za rozmowę :)