Situace
Typická situace u starší nebo přerostlé aplikace, kde se kombinuje technický dluh, slabší architektura a nejistý release.
Pomalá a křehká aplikace není jen technický problém. Promítá se do práce lidí, delšího delivery cyklu a slabší důvěry v další rozvoj.
Častou chybou je skočit rovnou do rewritu. Bez pochopení skutečných bottlenecků ale jen přesunete riziko jinam.
Pokud se situace nechá být, roste cena každé další změny a aplikace se stává bottleneckem místo opory pro byznys.
Začínám mapováním kritických míst, release rizik a částí systému, které dnes nejvíc blokují další delivery. Teprve potom dává smysl rozhodovat mezi stabilizací, refaktorem a větší změnou.
Cílem není jen rychlá oprava. Smyslem je vrátit projektu kontrolu, jistotu a rozumný další krok.
Ne. Nejprve je potřeba pochopit, co výkon opravdu brzdí a jaký dopad to má na provoz a delivery.
To je samo o sobě důležité zjištění. Část stabilizační práce často spočívá i v lepší viditelnosti do systému.
Ano. U většiny business aplikací je to praktičtější a bezpečnější než velký zásah naráz.
Další krok
Stačí krátce popsat současný stav, největší riziko a očekávaný další krok.