Dlaczego programy "enterprise" muszą być tak kosmicznie przekombinowane?

Byłem już w iluś projektach, ale w większości były stosunkowo niewielkie. Staraliśmy się, żeby kod był czysty i czytelny - pisaliśmy "dla siebie".
Ostatnio trafiłem do takiego "korpo-projektu" zrobionego przez jakichś szaleńców, którzy naczytali się 10000 książek o wzorcach projektowych, i oczywiście nie po to, żeby teraz nie wciskać tych wszystkich wzorców wszędzie, niezależnie czy ma to jakikolwiek sens czy nie. Nie można zrobić

int sum = 2 + 3;

tylko trzeba

Integer a = IntegerBuilder
  .fromPrimitiveInt(2)
  .withSign('+')
  .build();
Integer b = IntegerBuilder
  .fromPrimitiveInt(3)
  .withSign('+')
  .build();
Integer sum = OperationResultFactory
  .createResult()
  .withOperationType(operationUtils.getOperation('addition'))
  .withNumbers(ArrayOfNumbersHandler.getNumbersFromNumberListWrapper(ArrayOfNumbersHandler.createArrayOfNumbersFromIntegers(a, b)
  .doWhateverOtherUnnecessaryBsICouldThinkOf();

??
To jest jakieś kompletne szaleństwo. Nawciskane warstw abstrakcji, które nie rozwiązują żadnych problemów, tylko tworzą nowe. Chcesz zobaczyć, co się dzieje, np. jak wstawisz nowy rekord typu User do bazy? Nie wystarczy, że zerkniesz do UserTriggerHandler. Musisz iść do jakiejś bzdurnej TriggerHandlerFactory, która wywołuje jakieś inne bzdurne klasy, które wywołują inne bzdurne klasy, które wywołują inne bzdurne klasy, i dopiero po przebiciu się przez 5 warstw bzdurnych, niepotrzebnych abstrakcji dochodzisz do czegoś, co w poprzednich projektach było zwyczajnie UserTriggerHandlerem. Każda z tych klas "rozwiązuje" problem, który na 99% nigdy nie powstanie, za to tworzy kilka nowych, już teraz, kiedy ja potrzebuję naprawić jakiegoś buga w tej istniejącej logice.
Szczerze mówiąc to ten kod z tymi całymi "enterprise patternami" jest równie nieczytelny, jak hinduso-kod pisany przez ludzi, którzy znali tylko i wyłącznie struktury "if" i "for", i zagnieżdżali je 25 razy, żeby osiągnąć pożądany rezultat, tyle że ten hinduso-kod można było śmiało przerabiać po kawałku na coś bardziej sensownego i było to mile widziane, a tutaj oczywiście jest system zaprojektowany przez doświadczonych architektów, znających wszystkie wzorce projektowe i w ogóle, i tego betonu już nikt nie ruszy, do końca świata.
Ja wiem, że "kto nigdy nie strzelił do komara z armaty, niech pierwszy rzuci kamieniem", ale dla niektórych programistów, a zwłaszcza architektów, to jest po prostu styl życia. Dlaczego oni muszą to robić?! I dlaczego ja potem muszę to nieczytelne spaghetti napisane zgodnie ze wszystkimi SOLIDami i innymi śmiesznymi skrótami z ewidentnym pominięciem tego najważniejszego (KISS) utrzymywać?!
Nienawidzę tej roboty.
Rant over.

Ostatnio czytałem artykuł o tym, że w większości wielkich firm, zbyt szybko wyciąga się uzdolnionych devów na wyższe stanowiska, przez co w pisaniu kodu jest ciągły niedosyt ludzi, którzy rozumieją co robią (pomijając w ogóle, że mało jest ludzi z odpowiednimi predyspozycjami i realnym wykształceniem). Natomiast ludzie, którzy nie rozumieją musza pisać na pałę, w jeden z dwóch sposobów, które wskazałeś. Z dwojga złego, to podejście „overengineered” trochę łatwiej zmodyfikować na zasadzie dodania jeszcze jednej warstwy lub przekierowania z jednego miejsca w drugie, trochę łatwiej usunąć obiekt i przemieścić go.

korporacje to czesto przechowalnie dla slabych programistow.

Jest dużo przyczyn. Raczej nie chodzi o złośliwość:

• każdy kiedyś żałował, że nie zrobił gdzies dodatkowej warstwy abstrakcji, więc potem już wpiernicza w podobne miejsca, czy to ma sens czy nie (chyba sam najczęściej w tą pułapkę wpadam),
• chęć ogarnięcia projektu w jeden spójny sposób, więc produkujemy ultra generyczny pattern, który pasuje na wszystkie funkcje w projekcie (mimo że w 90% kodu jest overkillem),
• moda i kargo kult - widziałem, że kolega robił taki pattern więc też będę robił (nieważne, że to był inny projekt), ktoś na blogu pokazał fajny pattern... może się kiedyś przydać więc wrzucamy na zapas,
• braki w języku programowowania łatamy warstwami - (specyficzne dla javy i podobnych języków), tu trudno coś nawet poradzić,
• opór korpoarchitektów i korpomanagierów przed zmianami- nie można uprościć uprzednio wypracowanych patternów, bo poprzednie projekty tez były tak zasrane, ale się udały (w końcu z bólem weszły na produkcję) (to, że zwolniła się połowa programistów, a projekt przez 90% czasu był w fazie łatania błędów już umyka),
• specyficzny sposób pokazywania kto ma większe cojones (przez narzucenie własnego patternu, lub pokazywanie innym, że są głupi bo nie ogarniają),
• chyba na koniec najważniejsze: 95% korpoarchitektów wymyślających takie frameworki nie pisze w nich nic większego niż todo-list, nie widzi problemu

Skoro kasa jest proporcjonalna do ilości linii ...

Właśnie odnawiam kod w starszych projektach, i ogromne ilosci linii kasuję - chyba powinienem oddać kasę klientowi ?

Trzeba uwzględnić, że takie korpo-warstwy mogą rozwiązywać problemy w chwili T0, ale w chwili T0+2 lata, problemy z T0 są nieistotne. Kod został.

Nie słyszeliście nigdy "zróbmy jakieś założenia"? Moim zdaniem stopień abstrakcji/przekombinowania wynika ze stanu wiedzy dostępnej na moment projektowania systemu. Po tym jak projekt jest wdrożony często przychodzi refleksja "można to było zrobić inaczej, prościej... gdyby tylko na początku było wiadomo, że X, Y, Z". No ale bywa tak, że brakuje wiedzy o tych X,Y,Z. Jeśli chcemy czekać (przeważnie chcemy, ale z różnych względów nie możemy), to idziemy w kierunku waterfalla.

Jak sobie radzić z brakiem wiedzy o szczegółach X? Przykryć X dodatkową abstrakcją? Jak odwrócić zależność od nieznanego Y? Interfejs i dostawca usługi?

Czasem te skomplikowane patterny™ zwiększają poziom wejścia, ale gdy już zrozumiesz o co chodzi, jakie są konwencje itd. to faktycznie okazuje się że ma to ręce i nogi

Aczkolwiek konsultanci ewangelizujący też mają swoje za uszami :D

Kiedy gruboziarnisty kod jest lepszy?

Czy u was w pracy stosuje się Domain Driven Design?

@Crazy_Rockman powodów może być wiele i czasami faktycznie jest tak że trafia się "przeinżynierowanie", ale uważałbym z takimi rantami, szczególnie jeśli w projekcie jesteś "nowy" i nie rozumiesz jeszcze do końca wymagań biznesu ani gdzie ten projekt jest umieszczony w ekosystemie innych projektów. Jeśli masz jakieś HandlerTriggerFactory to sugeruje że takich handlerów może być wiele z czego ty możesz sobie nie zdawać sprawy.

Każda z tych klas "rozwiązuje" problem, który na 99% nigdy nie powstanie,

Bardzo śmiałe założenie, ale znów bardzo ryzykowne. Moze taki problem już faktycznie "powstał" i w odpowiedzi na niego 3 lata temu dodano obsługę? :)

Ten twój przykład z DSLem jest bardzo fajny, sam robiłem jakiś czas temu coś podobnego, więc się do niego odniosę. Nie będę sie tutaj rozwodził nad szczegółami, ale w wielkim skrócie potrzebowaliśmy kawałka kodu, który z jednej strony można "ewaluować", a z drugiej strony wygenerować na jego podstawie w innym systemie SQLa. Ktoś patrząc tylko na ten system który potrzebuje natychmiastowej ewaluacji wyrażenia też mógłby rantować że po co robimy jakiś cyrk z DSLem, skoro można było bezpośrednio napisać kawałek kodu...

Generalnie zalecam patrzeć na cudzy kod wychodząc z założenia, że autor wiedział co robi, a nie z założenia ze autor to debil. Widziałem wiele razy (i sam też się na tym łapałem) akcje w stylu "przepiszmy ten kawałek kodu, bo przecież da się to zrobić 100 razy prościej", co po kilku dniach/tygodniach kończyło się zaoraniem brancha, bo okazywało się, że jednak nie da się prościej, zeby obsłużyc wszystkie przypadki użycia i spełnić wymagania biznesowe.

Zgadzam się że czasami jest przekombinowane, taki "overengineering". Robi się go "przekombinujmy" po to żeby "przekombinować".

Ale z kolei innym razem, to co niektórzy odbierają jako "przekombinowanie", lub "utrudnianie prostych zadań", jest po prostu generalny/ogólnym podejściem do problemu - zbyt ogólnym dla tych którzy nie znają dziedziny. Dla kogoś kto nie zna dziedziny, i chce zrobić "jedną prostą rzecz", możę wydawać się dziwne że musi skorzystać z innych elementów - dla niego to jest przekombinowane. Ale to czego nie wie ta osoba, to to że jego potrzeba jest tylko jedną z wielu, i dodatkowo jest jedną z rodziny problemów - i tym "przekombinowanym" sposobem można rozwiązać całą taką rodzię problemów.

Innymi słowy, czasem przekombinowanie jest przekombinowaniem, faktycznie. Ale czasem przekombinowane jest coś tylko przez ignorancję, i tak na prawdę jest świetnym rozwiązaniem.

Przykładowo, dla kogoś kto jeździł na automacie całe życie ręczna skrzynia biegów może być przekombinowana. Albo dla programisty node'a C może być przekombinowane. Dla programisty Vue.js - Angular może być przekombinowany. Ale czy są takie w istocie? Czy po prostu są bardziej ogólnymi rozwiązaniami?

PS: PHP jest przekombinowany koniec kropka.

1. Bo programowanie na większą skalę jest trudne i ludzie próbują sobie radzić za pomocą tego co znają (mnóstwo wzorców projektowych "na zapas"), bo boją się spaghetti, które jest mało utrzymywalne. Problem w tym, że to, co potem powstaje, też jest mało utrzymywalne, ale cóż, nie dało się lepiej.

2. Bo języki są mało ekspresywne. Często mam wrażenie, że to, czego potrzeba, to języki, które by ogarniały abstrakcje za nas, zamiast klepania ręcznie tych abstrakcji w postaci "wzorców projektowych" czy wydziwionych wewnętrznych frameworków. Dodajmy do tego, że wiele programistów nie zna dobrze języków, w których pisze, więc nawet nie wykorzystuje w pełni możliwości języka i kod jest bardziej zagmatwany niż mógłby być.

3. Bo komercyjne i zespołowe pisanie ma dużą bezwładność. Pisząc sobie własny projekt hobbystycznie możesz popróbować różnych wzorców, a później stwierdzić, że dupa, to był błąd i przepisujesz wszystko od nowa w myśl zasady KISS. A w firmach się tak nie da, bo produkt już jest na produkcji, więc jak ktoś się pojechał za daleko z abstrakcjami, to już musi tak być. Chyba, że jednak podejmujemy decyzję o przepisaniu czegoś, ale to raczej zabawa na wiele dłużej, bo projekty są zwykle o wiele większe. Więc to przeinżynierowane legacy się ciągnie latami czasem.

Wyglada tak samo jak działa. Przecież klient musi wiedzieć, że płaci za produkt klasy enterprise ;)

A tak na serio, trudno zrobić czystą architekturę i ją utrzymać. Niektórzy pakują wzorce bez zastanowienia i spojrzenia na całość, tak to robili przez cała karierę zawodową i tak będą robić dalej.

Ja mam z kolei inną obserwację - czesty brak sensownych warstw abstrakcji i mieszanie kodu domenowego z infrastrukturą, np. encje JPA w logice biznesowej.

W momencie pisania tego kodu często nie są znane wymagania, więc (wydaje się, że) trzeba zrobić taki kod bardziej podatnym na wymagania, które pojawią się w przyszłości. Wymagania które były znane w momencie tworzenia kodu, przestały być wymaganiami w momencie w którym oglądasz ten kod. Możliwe, że w projekcie tydzień temu było szkolenie z wzorców projektowych/czystej architektury/pogadanka o SOLID, albo architekt przeczytał akurat jakąś książkę.

Przekombinowane rozwiązania, zazwyczaj mają bardzo pięknie brzmiące i stosunkowo proste uzasadnienia, dlaczego niby są takie świetne. Uniwersalność, możliwość konfiguracji i rozszerzania, użycie nowoczesnych narzędzi automatyzujących taką czy inną czynność... są dobrze wchodzącymi sloganami i nie wymagają jakiegoś dłuższego wstępu, aby pobieżnie tylko rozumiejący temat słuchacze nabrali entuzjazmu i pomyśleli - och, jakieś to mądre.

Jeśli ktoś z kolei rozumie jaki problem oprogramowanie ma rozwiązywać, ma doświadczenie w programowaniu i tej bądź pokrewnej dziedzinie, widzi że te entuzjastyczne wizje to puste slogany, i że to przekombinowane podejście stworzy mnóstwo problemów, a mało co rozwiąże, nie wytłumaczy tego w 15 minut jakiemuś członkowi zarządu, bo musiałby go wprowadzić w ogromną liczbę szczegółów, o których ten nie ma ochoty słuchać. Po wysłuchaniu obu stron, osoby decydujące ocenią rozwiązanie przekombinowane jako lepsze.

Fajnie jakby w tym wątku zostały podane przykłady przeinzynierowania, bo jak na razie mamy tylko jeden przykład z factory, który jak napisali poprzednicy wcale nie musi być przekombinowany :)

Albo nie, osobny wątek lepiej założyć.

Przykłady przeinżynierowanego kodu

No ten przykład z pierwszego posta @Crazy_Rockman z zamianą int sum = 2 + 3; na wywołanie jakichś bobów budowniczych to w zasadzie niedoinżynierowanie, bo to wygląda tak, jakby ktoś chciał osadzić jakiegoś DSLa/minijęzyk skryptowy w aplikacji (stąd potrzeba dynamicznej zmiany operatorów czy wartości) i zamiast odrobić pracę domową czyli napisać tego prostego DSLa albo poszukać istniejącego (co byłoby w zasadzie bardziej odważnym rozwiązaniem niż tylko wrzucenie paru wzorców więcej), to idzie na pół gwizdka i robi "DSL dla ubogich" w postaci

Integer a = IntegerBuilder
  .fromPrimitiveInt(2)
  .withSign('+')
  .build();

itp.

Tzn. przykład wygląda jak zmyślony, ale widziałem już podobne rzeczy naprawdę.

LukeJL napisał(a):

No ten przykład z pierwszego posta @Crazy_Rockman z zamianą int sum = 2 + 3; na wywołanie jakichś bobów budowniczych to w zasadzie niedoinżynierowanie, bo to wygląda tak, jakby ktoś chciał osadzić jakiegoś DSLa/minijęzyk skryptowy w aplikacji (stąd potrzeba dynamicznej zmiany operatorów czy wartości) i zamiast odrobić pracę domową czyli napisać tego prostego DSLa albo poszukać istniejącego (co byłoby w zasadzie bardziej odważnym rozwiązaniem niż tylko wrzucenie paru wzorców więcej), to idzie na pół gwizdka i robi "DSL dla ubogich" w postaci

Integer a = IntegerBuilder
  .fromPrimitiveInt(2)
  .withSign('+')
  .build();

itp.

Tzn. przykład wygląda jak zmyślony, ale widziałem już podobne rzeczy naprawdę.

Jak dla mnie, nie ma testu jednostkowego który mógłbyś napisać żeby rozróżnić Twój przykład z budowniczym od 2 + 3. Więc czemu miałbyś nie użyć "krótrszego" zapisu?

O apkach enterprajs to chyba można biblię napisać.

Ja troszkę odbiję piłęczkę.
Uważam, że prawie największy wpływ na kiepski kod ma ... biznes.

Ciągle niesprecyzowane wymagania, zmiana w locie, myślenie że bycie agile i mając scrum robią wszystko OK.
Przez to powstaje kupa w kodzie, nieważne jak dobrze zaczniesz, lebiegi z biznesu ubiją każdy soft w firmie.

Milion pomysłów na początku, którym ucina się łeb i potem coś na szybko trzeba sklecić z istniejącego kodu.

Porywanie się z motyką na słońce, porzucanie pomysłów, wypalanie programistów z w/w powodów.
Zatrudnianie najtańszych też de facto decyzja biznesowa, nie wpływa pozytywnie na jakość kodu :D

No i architekci też mają swój wkład, generowanie modułów z T4 i inne badziewia.

Większość tych rzeczy, które ludzie nazywają abstrakcjami, i zarazem to co opisał OP to tak naprawdę przekierowania/ pośredniość (indirection) a nie żadne abstrakcje.

Przekierowania i pośrednicy zwiększają stopień skomplikowania kodu. Każde miejsce gdzie możesz wpiąć inną implementację to przekierowanie. Im takich warstw więcej, tym kod czyta się trudniej, bo jest mało "mięska" a bardzo dużo "szkieletu".

Natomiast abstrakcja polega na tym, że zasadniczo upraszcza rozumienie kodu. Zamiast składać ręcznie bajty i pchać przez socket do bazy, od drodze jeszcze szyfrując, piszesz "addUser(user)" i sie robi. Dobra abstrakcja polega na tym że możesz opisać co robi takie "addUser" oszczędzając szczegółów jak to się tam naprawdę robi.

Abstrakcją jest baza danych, socket, plik, obiekt, iterator, drzewo, słownik itp. To są wszystko rzeczy dzięki którym pisze się prosciej bo pozwalają Ci trzymać w głowie znacznie mniej szczegółów (mniej niż wszystkie rzeczy faktycznie potrzebne do działania tych abstrakcji) a nadal jesteś w stanie ogarnąć system.

https://www.silasreinagel.com/blog/2018/10/30/indirection-is-not-abstraction/

Jeżeli sądzę, że coś można wykonać lepiej / prosciej to pytam autora kodu dlaczego zostało w ten sposób to zakodowane. Wtedy dosyć często autor opisuje sytuację, której nie wziąłem pod uwagę i daje sensowną odpowiedź. Dosyć często jest też druga odpowiedź. Gonił deadline i trzeba było robić na odpie*dol (npm przekopiować istniejący już kod z innego projektu) :D

W każdym razie, warto ze sobą rozmawiać i pytać.

Jak jestem w projekcie od początku, to robię review i pytam dlaczego tak, jeśli mam tego typu wątpliwości, ale w starym projekcie, do którego wpadłem miesiąc temu, a duża część autorów już dawno nie pracuje w tej firmie ta opcja nie istnieje.

ta opcja nie istnieje

Niekoniecznie.

1. Jest historia commitów i bardzo często zawiera odnośniki do jakiejś JIRY. Sprawdź skad się wziął ten "dziwny kod", kto i kiedy go dodał i co jest w commit msg
2. Są testy. Zobacz co się stanie jak spróbujesz "uprościć" kawałek kodu - ile testów akceptacyjnych się wysypie bo usunąłeś krytyczną funkcje systemu o której istnieniu nie masz pojęcia

Może faktycznie się w ten sposób z tym pobawię. W sumie dziś trochę też pogadałem z tech leadem projektu, i o ile sam przyznaje, że sam niektórych rozwiązań nie uważa za idealne, to trzyma się tego, co zastał, żeby była spójność (jestem w stanie to uszanować), to sens paru rzeczy był w stanie mi wyjaśnić. Ogólnie założyłem temat jako taki "rant", ale trochę spostrzeżeń forumowiczów, oderwanie się od kodu na weekend i pogadanie na spokojnie z leadem i już jestem do tego projektu nastawiony nieco bardziej optymistycznie. Także dzięki wszystkim, którzy zabrali głos :)

Ktoś tutaj fajnie to opisał wcześniej - ludzie trafiają do już istniejącego projektu, czasem long life. Taka osoba nie zna kontekstu powstawania takiego systemu, nie wie co się działo i jak powstawało.
Łatwo jest oceniać coś z boku po pewnym czasie. Pytanie czy mając tamte wymagania nie zrobilibyście inaczej?

Więcej dystansu w ocenie tego co zastajecie, bo często nie ma cie pojęcia w jakich warunkach kod powstawał i z czym się borykali ;)

To wszystko prawda, ale przekombinowanie bierze się też stąd że zwykli programiści:

• Nie umieją wcale pisać prostego kodu. I to nawet nie chodzi o brak YAGNI i cięcia funkcjonalności, tylko często ten sam kod potrafią napisać w sposób 3x bardziej skomplikowany niż mógłby być, zwykle przez niedostateczną znajomość języka, bibliotek lub zwyczajny brak zastanowienia się tylko klepanie pierwszego lepszego rozwiązania które przyszło im do głowy. Ostatnio np. gostek napisał kilkaset linii kodu parsujacego wyrażenia z OR i AND ręcznie ze stosem bo w projekcie w którym jest już ANTLR nie umiał zrobić gramatyki tak aby ANTLR parsował wszystko z dobrą precedencją operatorów. Ot, wolał napisać kilkaset linii niż doczytać jak zdefiniować kilka linii w ANTLR żeby wygenerować drzewko od razu z ANTLR. Innym razem inny senior zrobił drabinkę ifów na 6 przypadków, z czego dwa brzegowe niechcący pominął, a potem okazało się że wprowadzajac jedna zmiena pomocnicza można było to zredukować do bodajże jednego ifa, który był od razu poprawny.

• Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

Krolik napisał(a):

• Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

Niestety tak jest a w wykręcaniu się niektórzy są bardzo kreatywni.

@Krolik:

Nie umieją wcale pisać prostego kodu. I to nawet nie chodzi o brak YAGNI i cięcia funkcjonalności, tylko często ten sam kod potrafią napisać w sposób 3x bardziej skomplikowany niż mógłby być, zwykle przez niedostateczną znajomość języka, bibliotek lub zwyczajny brak zastanowienia się tylko klepanie pierwszego lepszego rozwiązania które przyszło im do głowy.

No ale przecież po to jest CR. Takie rzeczy powinny właśnie na nim wychodzić.

Ostatnio np. gostek napisał kilkaset linii kodu parsujacego wyrażenia z OR i AND ręcznie ze stosem bo w projekcie w którym jest już ANTLR nie umiał zrobić gramatyki tak aby ANTLR parsował wszystko z dobrą precedencją operatorów. Ot, wolał napisać kilkaset linii niż doczytać jak zdefiniować kilka linii w ANTLR żeby wygenerować drzewko od razu z ANTLR. Innym razem inny senior zrobił drabinkę ifów na 6 przypadków, z czego dwa brzegowe niechcący pominął, a potem okazało się że wprowadzajac jedna zmiena pomocnicza można było to zredukować do bodajże jednego ifa, który był od razu poprawny.

j.w. CR. PO to właśnie to jest aby unikać takich sytuacji.

Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

To też nie jest takie proste. Z jednej strony powinno się zostawić kod przynajmniej taki jaki zastaliśmy ale z drugiej strony jest ciśnięcie na terminy i często brakuje czasu...

Może trzeba być przypisane jakieś dodatkowe godziny na refactor? Np. na jakiś sprint wpada zadanie aby poprawić najbardziej śmierdzące kawałki kodu?

.andy napisał(a):

j.w. CR. PO to właśnie to jest aby unikać takich sytuacji.

Nie sprzątają. Jeżeli kod ma syf sprzed 10 lat, to znaczy że nikt nie sprzątał od lat. Nie można się wykręcać tym, że projekt ma 10 lat.

To też nie jest takie proste. Z jednej strony powinno się zostawić kod przynajmniej taki jaki zastaliśmy ale z drugiej strony jest ciśnięcie na terminy i często brakuje czasu...

Nie ma czegoś takiego jak brak czasu. Istnieje natomiast brak organizacji, lenistwo, brak potrzeby sprzątania, umiejętność spychania projektów na innych pracowników, etc.

.andy napisał(a):

Może trzeba być przypisane jakieś dodatkowe godziny na refactor? Np. na jakiś sprint wpada zadanie aby poprawić najbardziej śmierdzące kawałki kodu?

Sprinty naprawcze, refaktorowe, stabilizacyjne itp. Widziałem, przerabiałem, nie polecam. To jest takie zalegalizowanie syfu - robimy cały czas syf, a raz na jakiś czas poprawiamy - jeden ze sposobów jak wprowadzić projekt w bagno.
Prostsza metoda, która mi działała - przekonuje programistów, że zawsze przy szacowania mają podawać takie liczy, że uzwględniają:

• zrobienie dobrze zadania, z testami i review,
• z lekkim poprawieniem kodu dookoła - jak wiesz, że kod obok to syf to dajesz więcej

Jak prawie wszyscy w zespole mamy takie podejście, to się daje robić dobrze.
Brak czasu to raczej wymówka programistów. Wystarczy spytać projekt managera, PO czy kogoś tam czy chce aby zadanie było zrobione byle jak...

za y = a + b nikomu nie zapłacą 15k

za buildery z 10 warstwami abstrakcji już tak