<img src="https://www.daibau.cz/showfile.php?id=47977" style="max-width:410px;float:left;padding:10px 10px 10px 0px;border:0px;">Typickým problémem je rozdílné chování prázdných řetězců a NULL. MySQL ukládá prázdný řetězec jako '', zatímco PostgreSQL rozlišuje mezi '' a NULL – pokud aplikace spoléhá na prázdný řetězec, může dojít k logickým chybám. Dále si pohlídejte práci s celočíselnými děleními: v MySQL je 5/2 rovno 2, v PostgreSQL je to 2.5, což může rozbít výpočty. Proveďte důkladný test všech dotazů, zejména těch, které používají agregační funkce, GROUP BY nebo poddotazy.<br>
<br>
<br>
<br>
Nakonec nezapomeňte na beta testování se skutečnými uživateli. Dejte aplikaci vybrané skupině lidí, kteří ji budou používat v běžném provozu – v metru, na horách, na pomalém připojení. Jejich zpětná vazba odhalí problémy, které vám uniknou, protože vy znáte aplikaci příliš dobře. Teprve poté, co projdete fyzickými testy, automatizací i beta verzí, můžete aplikaci vydat. Pamatujte, že testování nekončí vydáním – sledujte chybové hlášení v produkční verzi a na základě dat z reálného provozu upravte své testovací scénáře.<br>
<br>
<br>
<br>
Psaní smysluplných commit zpráv je dovednost, která se vyplácí především při zpětné dohledatelnosti změn. Když se kód po měsících vrátíte, nebo když ho prochází jiný člen týmu, kvalitní zpráva ušetří hodiny zmatků. Nejde o žádnou vědu – stačí dodržet pár zásad, které vám i ostatním usnadní orientaci v historii projektu.<br>
<br>
<br>
<br>
Automatizované testy vám ušetří čas při opakované regresi, ale nejsou všelékem. Nejčastější chybou je testovat pouze „šťastnou cestu" – tedy situace, kdy vše proběhne bez chyby. Automatizaci nastavte tak, aby pokryla i chybové stavy: prázdná pole, špatný formát e-mailu, ztráta připojení k internetu, nedostatek úložiště. Pro psaní testů používejte nástroje, které umožňují běh na více zařízeních najednou, a testy rozdělte podle priority. Nízkoprioritní testy (např. vizuální kontrola) nemusí běžet při každém commitu, ale stačí je spustit před vydáním nové verze.<br>
<br>
<br>
<br>
Při práci s kontejnery se nevyhnete práci s příkazy. Základní je docker build pro vytvoření obrazu a docker run pro spuštění kontejneru. Mnozí začátečníci zapomínají, že kontejner po skončení běhu zmizí, pokud mu nezadáte přepínač -d (detached) pro běh na pozadí, nebo -it pro interaktivní režim. Tím se dostáváme k prvnímu typickému omylu: lidé očekávají, že kontejner poběží jako služba, ale ve výchozím stavu se spustí, vykoná úlohu a ukončí se. Pokud chcete, aby běžel stále, musíte buď spustit dlouhoběžící proces, nebo použít orchestrátor, jako je Docker Compose.<br>
<br>
<br>
<br>
Při odhadu implementace si všímejte technických rizik, neznámých závislostí a nutnosti integrace s jinými systémy. Tato rizika zvyšují čas, takže je započítejte do odhadu. Často se stává, že vývojář odhadne kód na 3 dny, ale zapomene na testování, code review, opravu chyb a nasazení. Stanovte si pravidlo, že odhad implementace vždy obsahuje i testy a „buffer" na neočekávané komplikace – obvykle 20–30 % navíc.<br>
<br>
<br>
<br>
Častou chybou je psát vágní fráze typu „oprava" nebo „update". Pokud nemáte prostor pro vysvětlení, alespoň upřesněte oblast: „oprava výpočtu daně ve faktuře" je stále lepší než „oprava". Dalším problémem jsou zprávy smíšené – když v jednom commitu řešíte dvě nesouvisející věci. Držte se pravidla jeden commit = jedna logická změna. Pokud to nejde, rozdělte to, i kdyby to mělo znamenat více menších commitů.<br>
<br>
<br>
<br>
Nakonec, běžnou chybou je ignorování velikosti obrazů. Každý obraz, který použijete, zabírá místo na disku a při přenosu mezi registry spotřebovává čas a data. Snažte se používat minimalistické základy, jako jsou varianty s označením -alpine, a kombinovat příkazy pro instalaci balíčků do jednoho řádku tak, abyste minimalizovali počet vrstev. Tím dosáhnete menších obrazů a rychlejšího nasazení. Až toto zvládnete, můžete se pustit do pokročilejších témat, jako je orchestrace nebo bezpečnostní skenování. Ale pro začátek stačí, když budete rozumět tomu, co děláte, a budete vědět, kde hledat, když se něco pokazí.<br>
<br>
<br>
<br>
Typickou chybou začátečníků je pracovat přímo na větvi master (nebo main). Pro každou novou funkci si vytvořte větev pomocí git branch nazev_vetve a poté na ni přepněte příkazem git checkout nazev_vetve. Tím se izolujete od stabilní verze a můžete experimentovat. Až budete s prací hotovi, sloučíte větev zpět pomocí git merge. Tento postup vám ušetří spoustu problémů, zejména když pracujete na více úkolech najednou.<br>
<br>
<br>
<br>
Git je nástroj, který sleduje změny v souborech a umožňuje vám vracet se k předchozím verzím. Pro začátečníka může být matoucí, ale stačí pochopit pár základních příkazů a workflow. Nejdůležitější je nejprve si Git nainstalovat a nastavit si uživatelské jméno a e-mail, protože bez nich nebudete moci vytvářet commity. Toto nastavení provedete příkazy git config --global user.name "vaše jméno" a git config --global user.email "vas@email.cz".
