Před spuštěním na produkci si připravte testovací prostředí se stejnou verzí PostgreSQL a stejnou kolací. Prožeňte aplikaci všemi scénáři, včetně prázdných výsledků a chybových stavů. Po přenosu dat spusťte ANALYZE, aby plánovač dostal statistiky. Zkontrolujte sekvence a identity — po hromadném importu je často potřeba posunout jejich aktuální hodnotu, jinak další vložení selže na duplicitní klíč. Migrace není jednorázový skript, ale několik ověřených kroků, které se vyplatí opakovat, dokud nejsou výsledky shodné.

Kde se migrace nejčastěji zasekne Největší překvapení přichází u textového vyhledávání a řazení. PostgreSQL rozlišuje velikost písmen a diakritiku podle kolace databáze. Dotazy, které v MySQL fungovaly díky výchozímu porovnávání bez ohledu na velikost písmen, mohou v PostgreSQL vracet jiné výsledky. Řešením je používat funkce pro porovnání nebo správně zvolenou kolaci. Podobně ukládání dat: MySQL toleruje neplatná data v DATETIME, PostgreSQL je odmítne. Na to narazíte při importu starších záznamů, kde jsou nuly nebo prázdné řetězce místo platného data.

Jakmile budeš mít funkční jednoduchou aplikaci, přidej druhou obrazovku a navigaci mezi nimi. Potom zkus uložit data tak, aby přežila zavření aplikace. Teprve pak řeš vzhled, animace nebo síťovou komunikaci. Když budeš postupovat po malých krocích, dřív zjistíš, co ti sedí, a hlavně budeš mít hotovou věc, kterou můžeš někomu ukázat. To je lepší než měsíce číst a nezkusit nic napsat.

Migrace z MySQL do PostgreSQL není jen převod typů sloupců. Rozdíly v chování serveru se projeví až v provozu: jinak se chovají transakce, jinak řazení textu, jinak výchozí hodnoty. Pokud začnete přepisem schématu bez přípravy, narazíte na chyby, které se v MySQL nikdy neobjevily. Nejprve si udělejte inventuru: které tabulky jsou kritické, kde se používají uložené procedury, triggery a kde aplikace spoléhá na nestandardní chování MySQL.

Pull request není jen místo pro schválení. Je to poslední šance odhalit chyby dřív, než se dostanou do hlavní větve. Nastavte si ochranu hlavní větve tak, aby vyžadovala alespoň jedno schválení a zelené testy. Do popisu pull requestu napište, co změna řeší a jak ji ověřit — recenzent pak nemusí hádat. Vyhněte se dvěma krajnostem: schvalování bez čtení a blokování kvůli stylistickým drobnostem, které patří do automatické kontroly.

Proměnné a prostředí místo ručního přepisován

Základem je jeden dokument, který drží pohromadě všechny endpointy a ke každému uvádí metodu, cestu, parametry, tělo požadavku, tělo odpovědi a seznam chybových stavů. Formát si zvolte takový, aby se dal strojově zpracovat — ručně psaný text v editoru se dřív nebo později rozejde s implementací. Popisujte i to, co se na první pohled zdá jasné: jak se předává autentizace, jak vypadá stránkování, jaké hlavičky jsou povinné.

Stavy, na které se zapomíná Největší rozdíl mezi prototypem a použitelnou aplikací jsou stavové obrazy. Vývojář často řeší jen ten šťastný případ: data dorazila, vše se vykreslilo. Ale co prázdný seznam? Co načítání? Co chyba sítě? Co neplatný vstup? Každá z těchto situací potřebuje vlastní obrazovku nebo alespoň text. Prázdný stav nemá být bílá plocha, ale krátká věta a výzva k akci. Chybová hláška nemá být „Error 500", ale co se pokazilo a co má uživatel udělat dál. Načítání delší než zlomek sekundy potřebuje indikaci, jinak uživatel klikne znovu.

Dokumentace má být snadno dostupná a ověřitelná. Ideální je stav, kdy si frontend sám vygeneruje klienta nebo si vyzkouší volání proti běžícímu prostředí. Zvažte nástroj, který umí z popisu vytvořit interaktivní náhled, ale nepřidávejte vrstvy jen proto, že jsou moderní. Důležitější je, aby popis odpovídal skutečnému chování a byl na jednom místě.

Nakonec nastavte proces. Každá změna kontraktu projde stejnou cestou jako změna kódu — návrh, kontrola, zapsání. Komunikace mezi týmy nemusí být formální, ale musí být včasná. Pokud backend přidá povinný parametr bez upozornění, frontend to odskáče v produkci. Dokumentace, která se aktualizuje společně s kódem, ušetří víc času než jakékoli vysvětlování na poradě.

Poslední věc, kterou vývojáři podceňují, je testování s někým jiným. Pusťte aplikaci člověku, který ji nezná, a mlčte. Sledujte, kde se zastaví, co hledá a co přehlédne. Většina problémů se ukáže během prvních minut. Neobhajujte design, jen si pište poznámky. Opravte to, co se opakuje u více lidí, a zbytek nechte být. UI/UX není jednorázový úkol, je to ladění stejně jako výkon nebo bezpečnost.

Typické chyby vznikají v detailech. Datum bez uvedení časového pásma a formátu, čísla jako řetězce, prázdné pole místo chybějící hodnoty, rozdílné názvy polí mezi seznamem a detailem. Frontend pak řeší obchvaty a backend se diví, proč se data zobrazují špatně. Sepište si proto jednotný slovník názvů a typů a držte se ho napříč celým API. Když se něco změní, změňte i dokumentaci a oznamte to.