Dodawanie ficzerów a dług techniczny

2

Team A musiał dodać ficzer do komponentu A. W trakcie pisania kodu okazało się, że część funkcji można napisać w sposób ogólny, niespecyficzny dla komponentu A, więc funkcje te wylądowały w pakiecie global.lib, aby inne zespoły mogły potencjalnie tego użyć. Przy czym tej funkcjonalności ogólnej nie było wcześniej nigdzie indziej w projekcie.

No i niby fajnie, a tu przyszedł architekt z zespołu B i stwierdził, że takie wrzucanie ogólnego kodu do ogólnego pakietu tak aby tylko jeden zespół tego teraz używał to generowanie długu technicznego i że albo przeniosą to do prywatnej części A, albo zostawia w ogólnych ale wtedy mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie, to nie ma mergowania.

No i teraz od godziny myślę nad tym i nie rozumiem - jak dorzucenie nowego kodu bibliotecznego ogólnego przeznaczenia z dokumentacją to generowanie długu technicznego? I jak niby dorzucenie tego samego kodu do prywatnego pakietu to już wtedy nie jest generowanie długu?

Tak myślę sobie, że przecież nawet jeśli po dorzuceniu tej biblioteki jakiś inny moduł powinien zacząć jej używać (aby np. uprościć kod), to przecież oznacza to tyle, że ten dług techniczny już był w tym module, a obecność libki tylko go uwidoczniła.

6

mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność

No jesli dobrze rozumiem, to analogiczny kod jest już w innych miejscach i w takim wypadku ma to pewien sens. Bo macie kolejny raz powieloną tą samą, lub zbliżoną, logikę. Oczywiście to nie tak, że zrobienie ogólnej libki "spowodowało" dług techniczny, tylko on już był (i jak schowacie tą libkę gdzieś u siebie to nadal będzie!) tylko ta libka go naświetla.

Tak myślę sobie, że przecież nawet jeśli po dorzuceniu tej biblioteki jakiś inny moduł powinien zacząć jej używać (aby np. uprościć kod), to przecież oznacza to tyle, że ten dług techniczny już był w tym module, a obecność libki tylko go uwidoczniła.

Dokładnie tak jest. Ale zauważ, że niektórzy mają mentalność "czego oczy nie widzą...". Szczególnie jak ktoś jest odpowiedzialny za projekt X a nie za projekt Y i w nosie ma duplikacje kodu pomiędzy tymi projektami.

3

Heca polega na tym, że ten kod nie jest powielony, a co najwyżej jest w jakiejś formie spaghetti-like. Jakby już gdzieś był, to zespół A by go po prostu użył (i być może trochę dostosował).

Wyobraź sobie, że każdy moduł zrobił sobie własną implementację listy łączonej która jest zrealizowana w miejscu użycia ad-hoc na wskaźnikach, tj. nie ma wydzielonego modułu, tylko te listy są takie ogólnie pomieszane z innym kodem - tj. logika biznesowa przepleciona z ustawianiem pointerow next i prev. Zero abstrakcji, 100% porytego kodu.

I teraz pojawia się zespół, który zauważa, że w sumie coś takiego jak lista to jest na tyle powtarzalna struktura, że można to wydzielić do biblioteki (lub nawet wziąć zewnętrzną bibliotekę) i kod staje się bardziej uporządkowany i czytelny.

Czy faktycznie odpowiedzialność za naprawienie całej reszty kodu musi spoczywać na tym kto zaproponował wydzielenie listy do osobnej klasy / struktury / modułu?
Przecież team A może nie mieć pojęcia o tym, gdzie ich lista się przyda w module B, C I D - musieliby znać cały kod, a w dużym projekcie to nierealne.

W ogóle jestem ciekaw jak walczycie z długiem technicznym w waszych projektach? Macie jakieś fajne systematyczne rozwiązania na to?

Dotąd widziałem kilka nieudanych inicjatyw:

  • każdy sprząta po sobie (scout rule) - działa tylko w małej skali i do powierzchownych rzeczy, ludzie unikają większego sprzątania
  • superhero big bang refactoring - "ale poryty kod, przepiszę go w weekend", a po 3 miesiącach: "już prawie działa".
  • "zaprojektujmy to porządnie" (waterfall?) - dwa tygodnie spotkań, brak konsensusu jak to powinno wyglądać, po czym nikt nie napisał ani linijki kodu przez kolejne lata....
1

W ogóle jestem ciekaw jak walczycie z długiem technicznym w waszych projektach? Macie jakieś fajne systematyczne rozwiązania na to?

Nie robić długu! ;) Każdy merge leci do review + jak ruszasz jakiś kawałek kodu to poprawiasz jeśli jest potrzeba.

superhero big bang refactoring - "ale poryty kod, przepiszę go w weekend", a po 3 miesiącach: "już prawie działa".

Nawet teraz takie robie, ale nikt się nie spodziewał że będzie po weekendzie, tylko raczej po kilku miesiącach ;) Pomaga też takie klasyczne 20:80, że 80% funkcjonalności można zrobić w 20% czasu. Najbardziej poryte rzeczy wypadły z backlogu i stary system stoi i obsługuje te corner case, szczególnie że one też niedługo w ogóle wylecą, bo są związane z innym serwisem, który też końcyz żywota za jakiś czas.

Jest też rozwiazanie ostateczne, czyli opakowanie czegoś adapterem, postawienie tabliczki "here be dragons" i pisanie nowych rzeczy dookoła.

6

Rozumiem zarówno postępowanie zespołu, jak i argumentację architekta z zespołu B (poza tym co jeśli każdy będzie dawał do global.lib swoje rutyny? Za chwilę będzie 5 konkurujących ze sobą rutyn). No ale tak jak przedmówca wspomniał - ten dług techniczny już tam jest widocznie, skoro ileś komponentów robi podobne rzeczy, ale na swój sposób.

A, albo zostawia w ogólnych ale wtedy mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie,

Nie zgadzam się z takim podejściem. Nie można dodać kawałka uniwersalnego kodu bez modyfikacji wszystkich modułów w projekcie? To nierozsądne podejście, bo dodanie gotowego kawałka uniwersalnego kodu:

  • trwa krótko, można to załatwić w 1 dzień wraz z code review.
  • nie niesie to ze sobą żadnego ryzyka, po prostu dodajesz

Natomiast przerabianie wszystkich modułów:

  • może trwać długo (zależy jak wielki projekt i ile jest modułów do przerobienia, ale w najgorszym przypadku będzie to gigantyczny refaktor na ileś sprintów).
  • jest ryzyko, że pewnych modułów nie uda się zmienić tak, żeby korzystały z tego nowego modułu (nie wiesz przecież jak są one napisane. Szczególnie, że piszesz, że to spaghetti-like. Może się okazać, że z jakich względów nie będzie to możliwe, ew. będzie trudne do tego stopnia, że nie będzie warto nawet inwestować w to czasu).
  • w przypadku, jeśli nie byłoby testów, dochodzi ryzyko, że po prostu coś się zepsuje w projekcie przy tak dużym refaktorze.
  • jest ryzyko, że wejdziesz komuś z butami w kod. I zmodyfikujesz komuś kawałek kodu, z którego korzysta. I potem będziesz zbierać bęcki i trzeba będzie cofać commity w Gicie albo rozwiązywać konflikty. I narobisz się na darmo.

Czyli w skrócie: dodanie funkcji do ogólnego pliku to rzecz trywialna. To, czego oczekuje architekt, czyli zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie, to nie ma mergowania. może okazać się nietrywialne (może, ale nie musi).

Można to porównać do zasady open-closed. Powinno się móc dodać coś do projektu bez konieczności modyfikowania wszystkiego.

to nie ma mergowania.

Jak dla mnie to ten commit powinien być jednak zmerdżowany, a dopiero w kolejnych sprintach można zająć się stopniowym refaktoringiem. Przecież zawsze można założyć nowego ticketa/tickety. Po to się pracuje na ticketach, żeby nie trzeba było robić wszystkiego naraz i żeby można było odroczyć moment robienia czegoś w czasie, bo nie wszystko musi być zrobione od razu.

No i refaktoringiem powinien się zająć zespół, który pisał dany moduł, bo oni znają najlepiej swoje moduły. Jak będziesz się wciskać w to, co robi inny zespół, to będzie jakieś pomieszanie odpowiedzialności. Czyli można to porównać do złamania zasady enkapsulacji.

0

my take:

Jak już ktoś zaczyna ruszać kupę, to niech poruszy ją raz i poprawi wszystko, a nie rozwleka to na pół roku.

Chociaż kod dostosować powinni Ci, którzy go pisali, no chyba, że wszyscy mają tam sensowne pokrycie testami ;)

@LukeJL

jest ryzyko, że pewnych modułów nie uda się zmienić tak, żeby korzystały z tego nowego modułu (nie wiesz przecież jak są one napisane. Szczególnie, że piszesz, że to spaghetti-like. Może się okazać, że z jakich względów nie będzie to możliwe, ew. będzie trudne do tego stopnia, że nie będzie warto nawet inwestować w to czasu).

no to się nie da, idziemy dalej, w czym problem?

2
Krolik napisał(a):

W ogóle jestem ciekaw jak walczycie z długiem technicznym w waszych projektach? Macie jakieś fajne systematyczne rozwiązania na to?

Dotąd widziałem kilka nieudanych inicjatyw:

  • każdy sprząta po sobie (scout rule) - działa tylko w małej skali i do powierzchownych rzeczy, ludzie unikają większego sprzątania
  • superhero big bang refactoring - "ale poryty kod, przepiszę go w weekend", a po 3 miesiącach: "już prawie działa".
  • "zaprojektujmy to porządnie" (waterfall?) - dwa tygodnie spotkań, brak konsensusu jak to powinno wyglądać, po czym nikt nie napisał ani linijki kodu przez kolejne lata....

W 2 firmach i 2 większych projektach (wieloletnie) zadziała metoda - nie pogarszamy, czasem lekko poprawiamy. Czyli boy scout rule. Jak już gdzies wchodzisz i dopisujesz ficzór to zobacz czy przy okazji nie możesz lekko nasprzątac dookoła (bez szału). Sporadycznie refaktoringi superhero na zasadzie, jak już widzimy jak zrobić lepiej perzystencje i mamy na to sposób sprawdzony w kilku przypadkach - to jakiś straceniec zamyka się na weekend i kosi projekt (to naprawdę sporadyczne wypadki -2-3 akcje na projekt, dokończenie pełzającego refaktoringu, migracja na nową javę). W sumie to zaskakujaco szybko widać było efekty (głównie poprawa morale - nagle ktoś się orientuje, że standardowe narzekanie na kod wypadło z tematów przy kawie).
Ważne, że musi być jakiś konsensus co to znaczy lepszy kod - to nie zawsze jest proste do ustalenia (jakaś wizja gdzie zmierzamy, biblioteki, practices itp).

W obu przypadkach projekt był naprawdę, naprawdę straszny( wizje szalonych architektów połączone z sabotażem w wykonaniu szeregowych koderów), ale generował dużo kasy, więc nie było problemów z budżetem, a biznes nerwowo reagował na hasła quick and dirty, bo już zdążyli wielokrotnie za takie pomysły zapłacić.

Mam też kilka pomnijeszych projektów, w kórych ugrzęzłem w brudzie, bo albo się nie dogadałem z zespołem co jest dobre (w dawnych czasach to częste było), albo uwierzyłem biznesowi, że projekt i tak zaraz będzie wyrzucony (daje się na to ciągle złapać - jak dziecko, nawet w ostatnim roku).

EDIT:
Dorabiałem też wizualizacje/ CI oparte o metryki, które pokazywały "czy nie pogarszamy". (Powiedzmy, że bardziej nachalne przezentowanie to co można wyciągnąć z sonara).
Robiłem to dla zabawy, w ramach manipulowania ludźmi i naciąganiu ich na głupawą grywalizację. Działa. Nawet rozdawanie medali działało :-) Nie będe narzekał, pomagało mi to i sam się na takie sztuczki też daję łapać. Chociaż bardzo możliwe, że ta grywalizacja nie odegrała istotnej roli, trudno mi ocenić - byłem autorem tych pomysłów i nie jestem obiektywny.

to generowanie długu technicznego i że albo przeniosą to do prywatnej części A, albo zostawia w ogólnych ale wtedy mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie, to nie ma mergowania.

Jak ktoś zostaje architektem to o nagle doskaje jakiegoś świra na punkcie spójności-homogeniczności (mi tęż kiedyś się zdarzyło). Pamietam jak jeden człowiek w końcu zadał pytanie czy naprawdę chcemy mieć cały projekt zły, ale konsekwentnie - spójnie zły, czy może zrobimy jeden moduł inaczej, ale lepiej...

Wyobraź sobie, że każdy moduł zrobił sobie własną implementację listy łączonej która jest zrealizowana w miejscu użycia ad-hoc na wskaźnikach, tj. nie ma wydzielonego modułu, tylko te listy są takie ogólnie pomieszane z innym kodem - tj. logika biznesowa przepleciona z ustawianiem pointerow next i prev. Zero abstrakcji, 100% porytego kodu.

Czy to jest kod w C pisany przez mamuty? Gdzie się takie cuda jeszcze pisze?

1

ogólnego kodu do ogólnego pakietu

Wszystko zależy od przypadku, a skoro piszesz o ogólnym kodzie to ja w ciemno zaryzykowałbym stwierdzenie, że wasz ogólny pakiet prawdopodobnie wyznacza jakieś nieszczególnie ciekawe interfejsy i narzuca wyjątki jakie wypada znać i obsługiwać. Taka zmiana to już nie ogólny kod ogólnego przeznaczenia, ale krok w kierunku standardu firmowego więc jest zasadność, by traktować tę zmianę jako wykraczającą poza zakres wybranego projektu. Myślę też, że taka rzecz prawdopodobnie uderza w ego innych architektów :-)

Przecież team A może nie mieć pojęcia o tym, gdzie ich lista się przyda w module B, C I D - musieliby znać cały kod, a w dużym projekcie to nierealne.

A jaki to problem by zorgranizować w frmie szkolenie/meeting? Przedstawiacie API, motywację jaka stoi za zmianami i czekacie na feedback i zielone światło.

W ogóle jestem ciekaw jak walczycie z długiem technicznym w waszych projektach? Macie jakieś fajne systematyczne rozwiązania na to?

  • Upominanie. Zwalnianie słabych, zatrudnianie lepszych.
  • Bazując na legendarny osobomiesiąc, tylko 1-2 najlepsze osoby powinny pisać kod, pozostałe osoby służą im pomocą np. wystawiają im prostsze biblioteki do użycia. Wtedy każdy będzie czuł się potrzebny, będzie miał realny i mierzalny wpływ, a także wzrośnie poziom spójności w rozwiązaniach, bo docelowo jeden autor bibliotki będzie za nią odpowiedzialny.
6

No cóż, to dość typowa sytuacja, którą mogę skomentować tak, jak to od dawna powtarzam - architekt w projekcie to skarb.
A skarby trzeba zakopywać głęboko pod ziemią.

3

Architekt ma racje a team blefuje.

  1. Nie należy tworzyć bytów ponad stan.
  2. Zakres takiego modułu jest za szeroki
  3. Jeśli jest jedno użycie to po co moduł? Podobna sprawa z pytaniem: czy jeśli interfejs ma jedna implementacja to czy powinien istnieć?
  4. Przedwczesna optymalizacja - juz teraz został utworzony wspólny moduł który może się przydać.
2

Jak dla mnie to ten commit powinien być jednak zmerdżowany, a dopiero w kolejnych sprintach można zająć się stopniowym refaktoringiem. Przecież zawsze można założyć nowego ticketa/tickety

Kontrargument jest taki, że to się nigdy nie dzieje i niespójny kod zostaje. Ale moim zdaniem to nie jest kwestia dodawania nowych rzeczy do kodu tylko braku pewnej kultury w całej organizacji, gdzie ludzie nie mają nawyku w sposób systematyczny poprawiać strukturę kodu (i często przepisywać fragmenty na lepsze).

Czyli jeśli inny zespół zrobił powiedzmy te listę ogólnego przeznaczenia, a mój kod używa wskaźników pomieszanych z logiką biznesową, to siadam i to poprawiam, zamiast mieć pretensje do kogoś innego.

A jaki to problem by zorgranizować w frmie szkolenie/meeting? Przedstawiacie API, motywację jaka stoi za zmianami i czekacie na feedback i zielone światło.

Czas. I to, że zaraz się zacznie się szukanie perfekcyjnego rozwiązania które rozwiąże wszystkie problemy i przez kolejny miesiąc ten komponent nie wejdzie.

Architekt ma racje a team blefuje.

  1. Nie nalezy tworzyc bytow ponad stan.
  2. Zakres takiego modulu jest za szeroki
  3. Jesli jest jedno uzycie to poco modul? Posobna sprawa z pytaniem czy jesli interfejs ma jedna implementacja to czy powinien istniec?
  4. Przedwczesna optymalizacja - juz teraz zostal utworzony wspolny modul ktory moze sie przydac.
  1. Zdefiniuj "ponad stan". SRP to jest zwykle dobry powód aby wydzielić osobny byt.
  2. Zakres czego? Jeżeli można małą ilością kodu ogarnąć wiele zastosowań to jest to dobra rzecz. Po to korzysta się z bibliotek, zamiast rzeźbić samemu stringi, listy czy słowniki.
  3. SRP, loose coupling, testowalność - można znaleźć wiele powodów. Poza tym któreś użycie zawsze musi być pierwsze i zawsze będzie moment, kiedy jest tylko jedno.
  4. Przedwczesna optymalizacja to zupełnie inny temat, ale niestety większość programistów nie zrozumiało o co chodziło Knuthowi z przedwczesną optymalizacją. A chodziło mu jedynie o to, aby nie optymalizować w ciemno komplikując niepotrzebnie kod, bez wykonania pomiarów. Tutaj nie mamy do czynienia z zaciemnianiem kodu tylko wręcz odwrotnie.
4

Nie znając szerszego kontekstu bliżej mi zdecydowanie do stanowiska architekta B. Każda dodatkowa wspólna zależność to koszt. Nie bez powodu w świecie mikroserwisów popularność zyskuje podejście shared-nothing nawet w odniesienie do kodu który się powtarza. Jak już są współdzielone jakieś fragmenty kodu, to są one zwykle opakowane w osobne produkty, dobrze udokumentowane, z dedykowanym zespołem które je utrzymuje i rozwija. A nie jako coś wrzuconego do wspólnego worka który jest własnością wszystkich, czyli nikogo.

Zresztą pociągnijmy sytuację dalej, niech teraz każdy zespół wydzieli sobie takie komponenty, które są unikalne w 97% dla ich modułu do tego wspólnego worka, ale nie uaktualnia tych pozostałych 3% w pozostałych projektach. Nagle się okaże że każdy moduł zależy od masy wspólnego kodu którego nie potrzebuje i nie używa, a który pokrywa się częściowo z tym co jest w danym module. Póki co nie jest źle, niech z czasem zacznie się mieszać ten kod z współdzielonych komponentów z kodem który robi to samo właściwym dla modułów, i w ten oto sposób powstaje tak zwana kula błota :).

Im mniej zależności między modułami tym lepiej, nawet często kosztem duplikacji kodu. Jak chcemy współdzielić jakiś kod, to naprawdę trzeba zrobić wszystko zgodnie ze sztuką (jak sugeruje architekt B) i nie brać drogi na skróty. Aczkolwiek niekoniecznie zadaniem przywrócenia spójności w całym projekcie musi być obarczony zespół który wprowadził ten wspólny komponent, ale dla dobra projektu ta spójność w zaplanowanym terminie musi zostać przywrócona.

0

Co do uzasadnienia architekta, to mętne.

Jeśli dług techniczny jest taki ważny, to co stoi na przeszkodzie, żeby Team A dostosował inne moduły do tego globalnego liba? Dyskusja z architektemB zakończona, dług zredukowany, profit. (Pojawia się pytania, kto zasponsoruje te zmiany? I po jakim czasie zwróci się ta inwestycja - innymi słowy: ile kosztuje dług techniczny, a ile jego naprawa?)

Dla mnie wygląda, że wyprodukowaliście liba, żeby rozwiązać potencjalne problemy innych zespołów, a te inne zespoły do tej pory nie zgłaszały, że mają problemy. Teraz mają problem, że trzeba dostosować komponenty do nowego liba, no chyba, że Team A to zrobi, to nadal nie będą mieli problemów.

Jeśli to globalna biblioteka i moduły uzyskają zależność od nowej biblioteki (więcej zależności, to lepiej?), to przecież przy developmencie ficzerów, które będą dotykały tego liba, pewnie trzeba będzie testować wszystkie komponenty (nawet te, które nie zostaną zmodyfikowane) i je potencjalnie dostosowywać do zmian. Czyli powstaje nowy dług?

1

Jeśli dług techniczny jest taki ważny, to co stoi na przeszkodzie, żeby Team A dostosował inne moduły do tego globalnego liba?

To znajdź teraz wśród 500k linii kodu, których nie pisałeś Ty ani Twój zespół te 100 linii, które mogłyby używać nowego komponentu a następnie nie znając projektu je dostosuj.

Teraz mają problem, że trzeba dostosować komponenty do nowego liba

Nie trzeba. Jeśli nie używają tej funkcjonalności to nie trzeba.
A jeśli używają, ale jej nie wydzieliły, to znaczy że napisali kupę spaghetti i powinni poprawić.

0
Krolik napisał(a):

Jeśli dług techniczny jest taki ważny, to co stoi na przeszkodzie, żeby Team A dostosował inne moduły do tego globalnego liba?

To znajdź teraz wśród 500k linii kodu, których nie pisałeś Ty ani Twój zespół te 100 linii, które mogłyby używać nowego komponentu a następnie nie znając projektu je dostosuj.

W drugą stronę jest to samo. "Weź teraz użyj funkcjonalności, której nie psiałeś Ty ani Twój zespół i nie wiesz czy działa tak jak potrzebujesz i co mi to ulepszy?" :-)

Chcąc jednak poprawić sytuację, to sensownym wydaje mi się:

  1. Umieścić funkcjonalność w moduleA
  2. Uruchomić inicjatywę, która ma na celu analizę wykorzystanie nowej funkcjonalności w innych modułach (tu jednak pojawia się problem, kto miałby to koordynować i jaki byłby z tego zysk, żeby ludzie widzieli wartość w tej analizie i wprowadzaniu zmian, a nie tylko problem "kto za to zapłaci/na co mam raportować")
  3. Na podstawie wyników tej analizy:
  • przenieść funkcjonalność z A do global
  • dostosować (bo będzie wiadomo co) inne moduły do global

...albo porzucić ideę re-użycia funkcjonalności. No chyba, że mamy pozycję 'Ma tak być i koniec', a nie atakujemy problemy z dołu :)

2
yarel napisał(a):
Krolik napisał(a):

Jeśli dług techniczny jest taki ważny, to co stoi na przeszkodzie, żeby Team A dostosował inne moduły do tego globalnego liba?

To znajdź teraz wśród 500k linii kodu, których nie pisałeś Ty ani Twój zespół te 100 linii, które mogłyby używać nowego komponentu a następnie nie znając projektu je dostosuj.

W drugą stronę jest to samo. "Weź teraz użyj funkcjonalności, której nie psiałeś Ty ani Twój zespół i nie wiesz czy działa tak jak potrzebujesz i co mi to ulepszy?" :-)

Nie do końca, bo jednak współdzielone biblioteki powinny mieć dokumentację i ich API powinno być projektowane tak żeby mogli go używać ludzie którzy nie pisali tej biblioteki

4

No i niby fajnie, a tu przyszedł architekt z zespołu B i stwierdził, że takie wrzucanie ogólnego kodu do ogólnego pakietu tak aby tylko jeden zespół tego teraz używał to generowanie długu technicznego i że albo przeniosą to do prywatnej części A, albo zostawia w ogólnych ale wtedy mają zmodyfikować wszystkie moduły tego projektu, aby też tego używały, bo musi być spójność, i dopóki to się nie stanie, to nie ma mergowania.

Jeśli przykład przypomina tak jak piszesz liste, zacząłbym od wykłocenia się zeby z mergować sie osobno. To co powiedział Pan Architek jest elementernie głupie, niech spada na drzewo banany prostować. Zdenerwowało mnie to.
Powiedz mu że przemyślałeś to o czym rozmawialiście. Skoro on sam uwaza ze Twoje rozwiazanie powinno być stosowane wszedzie w projekcie, to znaczy że sam stwierdził że Twój kod jest dobry. A skoro Twój kod jest dobry, to dalsze opóźnianie merga łamie zasady rozwoju oprogramowania i nie powinno mieć miejsca. Generalnie ze sie nie z min zgadzasz, zwłaszcza jak coś marudzi pod nosem.

Uważam że problem powinien być rozwiązany tak jak opisał to @LukeJL, stworzenie sobnego taska, i stoponiowy refaktoring.

Kontrargument jest taki, że to się nigdy nie dzieje i niespójny kod zostaje

Dodanie taska rozwiązuje ten problem, bo skoro masz zadanie do wykonania to je wykonasz, Prosta sprawa.

Ewentualnie, możesz mówic że zadanie XYZ, które robiłeś, nie zawiera dotyczy, modół A, B, C. I przemycanie zmian do innych modułow jest nie spójne i nie transparetne, oraz utrudni wczesne wykrycie błedów. Błedy wykryte późno kosztują wiecej, a wiec robienie tego w jednym tasku ładmie podstawowe zasady wytwarzania oprogramowania.
Ten sam argument z defektami możesz uzyć żeby uragumentować, to dego by nie opóżniać merga, bo wczesny merge pozwoli wykreć ewentualne błedy lokalnie, a nie na poziomie całego systemu. Możesz też go ciesnać ze zmienianie całego systemu w jedym mergu, to zły pomysł, bo ludzie są omylini, istnieje pewne prawdopodbieństwo że modyfikując nie swój kod:
wyłożysz pół systemu, a nie jeden feature,
wyłożysz feature otórego istnieniu nie wiesz,
wprowadzisz błąd który cieżko bedzie wykryć
ewentualnego błędu nie wykryjesz Od razu bo nie pracujesz w tym module na codzień -> znajdzie go ktoś inny przed tobą i poświeci duzo czasu na inwestygacje
testowanie będzie trudne, bo wymaga kordynacji kilku zespołów, albo lepiej zapytaj sie go komu masz przypisać te zadania do testowanie, bo tester X nie jest w dożony w prace z modułem Y

Generalnie łamie to podstawowe zasady wytwarzania oprogramowania, powinnien ustąpić. W razie oporów asertywnie mówisz ze się z nim nie zgadzasz, albo pytać w jaki spoób pojedyczy merge uzasadnia wystawienie systemu na ww ryzyka.

4

Wg. mnie są 3 poziomy dojrzałości w zarządzaniu długiem technicznym:
0. Wprowadzamy dług techniczny i zapominamy (chaos, droga do śmierci)

  1. Nie wprowadzamy długu technicznego (idylla, produkt nigdy nie wejdzie na rynek)
  2. Świadomie zarządzamy długiem technicznym (kontrola)

Dla mnie z dt jest jak z kredytem inwestycyjnym - można zaciągnąć, żeby mieć krótki TTM, ale trzeba go kontrolować i sukcesywnie spłacać.

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