Pokročilý průvodce
Když se aplikace špatně mění, láká čistý restart. Jenže bez pojmenování skutečných příčin může rewrite jen přesunout stejné riziko do nového kódu.
Úplný přepis aplikace může dávat smysl, ale jen ve chvíli, kdy stávající systém opravdu blokuje provoz nebo další rozvoj natolik, že cílené zlepšování už nefunguje.
Silnější rozhodnutí nevychází z dojmu, že je kód starý nebo nepříjemný. Vychází z dopadu na byznys, release riziko, rychlost změn a cenu dalších zásahů.
Důležité nejsou estetické výhrady ke kódu, ale opakované situace, kdy architektura nebo data blokují bezpečný provoz a každou další změnu prodražují.
Pokud aplikace stále drží důležitý provoz a největší problémy jsou soustředěné v menším počtu částí, bývá bezpečnější a levnější začít stabilizací, modularizací a cíleným přepisem vybraných oblastí.
Praktické rozhodnutí potřebuje audit závislostí, dat, release cesty, provozních omezení a toho, jak moc by firma zvládla paralelní vývoj bez ohrožení běžného provozu.
Nejslabší důvod pro rewrite je únava z cizího kódu. Nejsilnější důvod je opakovaně potvrzený dopad na provoz, bezpečnost nebo delivery, který už nejde rozumně řešit postupně.
Ne. Důležité je, jaké konkrétní problémy způsobuje provozu, bezpečnosti a rychlosti dalšího rozvoje.
Ano. U mnoha aplikací je selektivní rewrite nebo oddělení nejproblematičtějších částí praktičtější než kompletní restart.
U běžící business aplikace ano. Bez auditu se těžko rozlišuje mezi skutečnou nutností a pouze silnou frustrací z aktuálního stavu.
Další krok
Pošlete základní kontext a navrhnu rozumný další krok.