Když chcete ověřit reducery a async akce bez běžícího prohlížeče

První skutečný projekt ať je malý, ale dokončený. Ideálně aplikace, kterou sami použijete: poznámky, jednoduchý převodník jednotek nebo sledování návyků. Rozdělení do obrazovek navrhněte na papíře dřív, než napíšete první řádek. Zjistíte, že většina chyb nevzniká v kódu, ale v nejasném zadání. Každou obrazovku postavte jako samostatnou část, která dostane data z jednoho místa. Když se data začnou tahat z pěti různých zdrojů, aplikace se rozpadne při první změně.

Druhý častý problém je práce s transakcemi a zámky. MySQL má výchozí autocommit a特定 chování u nevýkonných dotazů, PostgreSQL je přísnější. Dlouhé transakce blokují úklid starých verzí řádků a mohou nafouknout databázi. Při migraci proto zkontrolujte, zda aplikace neotevírá transakce zbytečně dlouho. Pozor také na ON DUPLICATE KEY UPDATE — v PostgreSQL použijete INSERT … ON CONFLICT. Nahrazení není mechanické, musíte určit konfliktní sloupec.

Ladění berte jako běžnou součást práce, ne jako trest. Nastavte si logování s jasnými značkami a čtěte výpisy chyb odshora dolů, protože příčina bývá v prvních řádcích, ne v posledním. Při každé chybě si napište do poznámek, co ji způsobilo. Po měsíci budete mít vlastní seznam, který je cennější než jakýkoli kurz. Nebojte se používat simulátor pro rychlé kontroly a skutečný telefon pro chování na dotyk, baterii a pomalé síti.

Jakmile první aplikace běží, nespěchejte s jejím zveřejněním. Nechte ji týden používat někým jiným a sledujte, kde se zasekne. Verzujte kód od prvního dne, i když pracujete sami. Zvykněte si psát krátké popisy změn, které za půl roku pochopíte. Až budete mít hotové dvě až tři malé aplikace, teprve pak má smysl řešit publikaci, propagaci a další růst. Do té doby je každá hodina strávená u kódu investicí, která se vrátí v podobě klidnějšího vývoje.

Poslední vrstvou je omezení práv databázového účtu. Aplikační účet nemá mít právo měnit strukturu, vypínat triggery ani přistupovat k tabulkám, které nepotřebuje. Když se injektáž přesto prosadí, škoda zůstane omezená. Kontrolu dělejte pravidelně, ne jednou při nasazení. Práva se v čase rozšiřují a zapomenuté granty zůstávají. Bezpečnost není jednorázové nastavení, ale rutina, která přežije i vaše další vydání.

Asynchronní kód je místo, kde se čistota láme nejčastěji. Místo řetězení .then() a .catch() používejte async/await a obalte volání do try/catch. Nikdy nezapomeňte na await u funkce, která vrací promise. Typická chyba je, že zapomenete await a pak se divíte, proč máte v proměnné promise místo dat. Stejně tak nedávejte await do cyklu for, pokud nechcete čekat postupně. Když potřebujete paralelní zpracování, použijte Promise.all.

Testování reducerů a asynchronních akcí bez integračního prostředí znamená, že pracujete pouze s čistými funkcemi a nástroji, které nepotřebují běžící aplikaci ani síť. Redux reducery jsou ideální kandidáti: jde o čisté funkce, které dostanou stav a akci a vrátí nový stav. Žádné vedlejší efekty, žádné volání API. Pokud tedy testujete reducer, nepotřebujete žádný prohlížeč, stačí testovací runner a hluboká znalost výchozího stavu.

Pro síťové volání použijte stub nebo mock. Nahraďte funkci, která volá API, za jednoduchou funkci, která vrací Promise.resolve s předpřipravenými daty. Stejně tak otestujte chybovou větev: Promise.reject s chybou. Po zavolání async akce počkejte na dokončení Promise. To je místo, kde lidé chybují nejčastěji: zapomenou na await nebo na vrácení Promise z testu. Testovací runner pak skončí dřív, než se akce dokončí, a vy dostanete falešně pozitivní výsledek.

Rozhodnutí psát aplikace pro Android vypadá jednoduše, dokud neotevřete první projekt. Najednou stojíte před desítkami souborů, konfigurací a pojmů, které spolu zdánlivě nesouvisí. První týden proto věnujte pochopení základní architektury, ne hromadění hotových řešení. Nainstalujte si vývojové prostředí určené přímo pro Android, ne obecný editor s doinstalovaným pluginem. Tím získáte simulátor, správce závislostí i nástroje pro ladění v jednom celku. Vyberte jazyk, který je pro platformu oficiální a dlouhodobě podporovaný, a držte se ho alespoň první tři měsíce. Přeskakování mezi dvěma jazyky na začátku jen zpomalí učení.

Začni názvy. Proměnná data, temp nebo x neříká nic. Místo d napiš datumObjednavky, místo arr klidně seznamKurzu. U funkcí používej sloveso: spocitejCenu(), nactiUzivatele(). Pokud název potřebuje komentář, je pravděpodobně špatný. Boolean pojmenuj jako tvrzení: jePrihlasen, maOpravneni, ne flag.

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.