MLEKAR_STEIN: Tak záleží jak moc máš smůlu a kdy narazíš na nějaký tvrdý limit toho frameworku. Ted dělám na produktu, kterej byl tři čtvrtě roku psanej na Faust framework (Kafka/python), aby se pak ukázalo, že to hlavní (horizontální škálování) v tom frameworku v podstatě nefunguje a pak se většina appky přepisovala, abychom se toho zbavili.

MLEKAR_STEIN: Moje zkusenost je, ze prepisy jsou kosmicky jednodussi, pokud ma ta vec dobre navrzeny a srozumitelny interfacy (at uz APIs knihoven, nebo nejaky sitovy service APIs).

Bohuzel teda typicky clovek zjisti jak je spravne navrhnout az po tom co to napise, a aby to udelal dobre tak by to vlastne musel prepsat do v2 a…ohwell.

MLEKAR_STEIN: bez frameworku se to dneska IMO neda. Ale snazime se vybirat neco, co neni prilis specificke a nepouzivame ho uplne na dren (konkretne ted jedeme Kotlin + Micronaut a dovedu si predstavit, ze migrace na Spring nebo Quarkus by nebyla zas tak tezka, snazime se pouzivat spis primocare DI a nezabredavat do nejakych prilis chytrych vychytavek).

me prijde, ze se s technickym dluhem neda nic moc delat. i kdyz to na zacatku je dobry, a ani se to moc nezprasi, tak to stejne bude za par let nic moc.
treba jednoduche zalohovaci scripty. Kdysi jsem si napsal zalohovaci scripty. Byly blbe napsany, protoze jsem shell neumel a nedaly se konfigurovat a nemel jsem na to cas atd. Casem jsem si uskubl cas z jinejch veci a postupne je prepsal. daly se nejak konfigurovat, byly i o neco lepe naspane. ale stejne, kdyz jsem se do nich po par letech podival, tak nebyly proste dobre. musely se trochu prepsat. tentokrat uz jsem na tom netravil moc casu. proste jsem tam pridal nejakoou blbost, co jsem poterboval a hotovo.
co mi prislo jako zasadni, ze jsem si pri prepisu pomerne dobre definoval, co to teda ma delat. melo to nejak smysluplnou konfiguraci a nejak definovany vystupy, jako ze co ma logovat a kam, jak ma v konfiguraci vypadat popis odkud se zalohuje a kam se zalohuje. a dokud tohle je vice mene stejne, tak to docela jde.
no a protoze to porad stejne neni, tak mam takovejch zalohovacich veci napsanejch vicero. vice mene si jsou podobny :)
ale nejsem schopnej udelat neco, co by se dalo nazvat obecne produktem a nejak obecne pouzivat. :)

KOJA: k tomuhle pocinu me dohnaly jiz zmineny faktory + vyuzil sem tak trochu toho, ze sem byl jedinej core programator kterej si moh tak trochu dupnout... Spis sem tohle rozhdnuti uvadel proto, ze se do takovyhle souhry asi uz nedostanu... Dalsi vec je to, ze puvodni kod byl jinak docela pruhlednej, plno veci bylo tak trochu copy/paste, takze sem uz dopredu vedel ze me necekaj naky extra pasti.
v nasledujicim zamestnani uz sem podobnej zamer viditelne brzdil jako clen tymu (prestoze sem patril spis k "diverzantsky" casti), protoze sem si byl vedomej komplexity celyho projektu, bylo to vseobecne velky sousto a nebyl si jistej zda bysme byli schopni se dohodnout na finalni forme.
A kdyz sem pak podobny veci resil ze zodpovednejsiho postu kde sem musel resit vicemene i zdroje, bylo mi jasny ze je to dost nakladna zalezitost. Ono kdyz se pro neco takovyho tym rozhodne, je treba si bejt jistej ze nekdo stezejni v pulce neodejde nebo ze ho neprelozej nekam jinam, stejne tak si clovek musi bejt jistej s jeho kompetencema - to ze dotycnej dovede najit chybu a commitnout fix kterej zachrani v danym momentu situaci neni zaruka toho, ze je dobrej i na to aby napsal komplet nakej novej modul kvalitne a i z hlediska udrzitelnosti.
Momentalne treba resim komplet refaktoring jednoho z projektu taky (puvodni kod napsal kolega toho casu cerstvej absolvent, cca pred 3 rokama), nicmene pokud se k tomu opravdu rozhodnem, bude to jenom pro novou verzi nasazenou do uplne rozdilnyho prostredi, kde by portovani stavajiciho reseni bylo pracnejsi nez to napsat znovu ... a ano, porad sem v ty euforii ze se to musi komplet prepsat protoze z hlediska maintenance to bude cimdal vetsi horror (vlasy si rvu denne kdyz se v tom hrabu), ale zustavam porad pragmatictejsi, protoze pro klienta to bude mit porad mizivou pridanou hodnotu v dohlednym horizontu (tj. par let).

ABAP: My nebyli velký korporát, ale naši zákazníci byli čistě interní. Takže šlo argumentovat že to buď bude náš čas na přepsání, nebo pak artist time před deadline když něco nepůjde doprogramovat dost rychle a budou to muset řešit manuálně. Ale to jsme měli velmi osvícené a technické vedení až po majitele včetně.

frontendy se takhle asi dělají všude? my to teda takhle nějak děláme :-)
Interview with Senior JS Developer in 2022
https://www.youtube.com/watch?v=Uo3cL4nrGOk

CERMI_FOX: Ja jsem to mel asi napsat jinak. Ja coby vyvojar mam celkem jiste nejaky bias. Manazeri, nekdy i ty technicky zdatni jako treba ex-vyvojari, mivaji zase jiny bias. Problem vidim v tom, jake presvedcive argumenty pouzivat. Idealne nejake jednoduche a snadno dolozitelne fakty. Protoze si umim predstavit, ze kdybych byl ve vedouci pozici a prisel za mnou vyvojar s tim, ze je nezbytne nutno ted pulroku blahodarne pusobit na kod “prozoze proto”, tak to taky neodkyvu.

Ja s tebou taky souhlasim ale bohuzel mi prijde, ze je tezke o tomhle presvedcit nekoho kdo se denodenne nerype v konkretnim kodu.

KOJA: postupný přepisování/refactoring má spoustu výhod a důvodů, který je třeba dát do té rovnice vyplatí/nevyplatí, jen tak z hlavy o půlnoci z mých zkušenosti:
* končící support a dostupnost security oprav
* zhoršující se maintainability - původní design modulu nebo systému nestačí novým požadavkům - změny trvají čím dál déle, častěji se chybuje, bohužel když je tohle zřetelně vidět, tak už bývá pozdě, resp cena refactoringu je už hodně vysoká a spirála zvyšující se náročnosti odkládáním je na světě
* lidi odchází a znalosti s nima, v hlubinách battle tested kódu jsou místa, o kterých nikdo neví, proč tam jsou, ale všichni se je bojí odstranit. Testy nevyřeší vše; je to nějaký starý request od klienta? Performance? Race condition?
* nábor - na prasecký kód je čím dál těžší nabrat nový dobrý lidi - starý lidi přirozeně odchází a nechci dělat s novýma špatnýma lidma
* nový framework může přinést performance benefity (třeba přechod z .netfw na .net6 - možná je to na jiných platformách jinak; u C se tohle asi neřeší :) )


Tvoje body jsou validní, nezpochybňuju, jen mám zkušenost, že management, co rozhoduje o budgetu, nebývají vývojáři, ale manageři z povolání, netechnický lidi, o to horší je jim vysvětlit + a - refactoring vs nicnedělání a všechno přepočítávají na prachy (na druhou stranu by někdo mohl podotknout, že je možné s nima lépe manipulovat).
Prostě je třeba to vyvážit

KOLCON: Duvodu proc se udrzba zanedbava si umim predstavit hodne.

- Management (predchozi generace vyvojaru) nevnima problem jako urgentni.
- Projekt stejne vyhledove speje ke konci a prepsani by neprineslo dostatek uzitku.
- Vedeni pamatuje programovani pred 20 lety a tudiz je z jejich pohledu projekt v poradku.
- Snaha vyzdimat s danou lidskou kapacitou z projektu co se da s vizi, ze v urcitou dobu bude stejne prekonan (prepise to konkurence nebo open-source).
- “Ted na to neni cas.”
- Battle-tested - pres veskere neduhy je prasecky kod odladeny na milionech uzivatelu a jakykoliv prepis smrdi pruserama. Treba se projekt odladil na nadsenych early adopterech nez se stal kritickym.
- …


V realu to asi bude kus od kusu a jeste casto asi nejaka kombinace. Problem vidim spis v opacne otazce - jake jsou dobre a presvedcive duvody do prepisovani/refactoringu kodu?

KOLCON: neochota zákazníků to platit