Pozor i na příliš vágní formulace. Slova jako „oprava", „úprava", „vylepšení" nebo „refaktoring" bez bližšího určení nenesou žádnou informaci. Místo „Refaktoring kódu" napište „Odděl logiku pro výpočet slev od zpracování objednávky". Podobně se vyhněte hláškám typu „drobné úpravy", které neříkají, co bylo změněno a proč. Pokud je změna opravdu triviální, raději ji slučte s jinou smysluplnou.<br>
<br>
<br>
<br>
Poslední rada: pyramidu neberte jako dogma, ale jako výchozí bod. U projektu s bohatým uživatelským rozhraním a složitou logikou na klientovi bude poměr jiný než u REST API bez frontendu. Důležité je, abyste se rozhodovali vědomě a ne náhodně. Měřte si dobu běhu, počet selhání a čas strávený údržbou. Jakmile uvidíte, že opravy testů žerou víc času než psaní nových funkcí, je čas pyramidu přebudovat. A to je přesně ten moment, kdy se vyplatí mít na paměti, proč pyramida existuje – ne pro krásu, ale pro efektivitu.<br>
<br>
<br>
<br>
Nezapomínejte také na rychlost. Testovací pyramida není jen o počtu testů, ale o čase, který jejich spuštění zabere. Ideální je, když jednotkové testy běží do pěti minut, integrační do patnácti a E2E do hodiny. Pokud vám E2E běží déle, rozdělte je do skupin podle kritičnosti a spouštějte je v noci. Ale pozor – noční běh znamená, že chybu objevíte až ráno. Proto se vyplatí mít aspoň pár klíčových E2E testů v CI, které běží při každém commitu.<br>
<br>
<br>
<br>
Po migraci spusťte sadu testů, která porovná výsledky dotazů na obou databázích. Zaměřte se na dotazy s datem, textem a agregacemi. Typická chyba je v použití funkce DATE_FORMAT, kterou PostgreSQL nemá – musíte ji nahradit funkcí TO_CHAR. Ujistěte se, že vaše aplikace používá ovladač pro PostgreSQL a že je správně nakonfigurována pro práci s novým typem vrácených dat.<br>
<br>
<br>
<br>
Nebojte se psát delší názvy, ale vyhněte se zbytečným komentářům Nejčastější chybou je komentovat, co kód dělá, místo toho, abyste kód napsali tak, aby to bylo jasné samo. Dobrý název proměnné je lepší než komentář. Místo let x = getValue() napište let totalPrice = calculateTotalPrice(). Ale pozor na přehnanou délku — listOfAllAvailableProductsInTheCurrentSession už nikdo nepřečte. Zkuste se držet rozsahu dvou až čtyř slov a vždy myslete na kontext. Pokud jste uvnitř funkce zpracovávající objednávky, items je jasné, pokud jste na globální úrovni, raději orderItems.<br>
<br>
<br>
<br>
Když tým začne psát automatizované testy, většinou skončí u rozsáhlých end-to-end scénářů, které procházejí celou aplikací. Na první pohled vypadají solidně, ale po pár týdnech se ukáže pravý opak: běh trvá desítky minut, každá změna v rozhraní rozbije desítky testů a doba opravy převyšuje čas, který testy ušetří. Základní poučka zní: čím výše v pyramidě test stojí, tím je dražší na údržbu a tím méně jich má být. Přesto ji týmy soustavně ignorují a pak řeší důsledky.<br>
<br>
<br>
<br>
Nakonec myslete na to, že čistý kód je výsledkem neustálé údržby. Když vidíte, že se vám funkce opakují na dvou místech, zobecněte je. Když se vám zdá podmínka příliš složitá, vytáhněte ji do samostatné funkce s výstižným názvem. A pokud se vám zdá, že kód dělá příliš mnoho věcí, rozdělte ho. Pravidlo je jednoduché: kód by měl být čitelný pro kolegu, který na projektu začne pracovat zítra, a pro vás samotné za půl roku. To je důležitější než jakákoli optimalizace výkonu.<br>
<br>
<br>
<br>
Nastavte si jednoduchý model větvení dřív, než začnete psát kód Nejčastější chybou je, že každý používá jiný styl pojmenování větví a jiný postup slučování. Někdo dělá merge, jiný rebase, někdo pushuje přímo do hlavní větve. Přitom stačí zvolit jeden jednoduchý model a dodržovat ho. Ideální je začít s hlavní větví, která vždy obsahuje stabilní verzi, a pro každou novou funkci nebo opravu vytvořit samostatnou větev. Název větve by měl být stručný a výstižný, nejlépe s číslem úkolu, aby bylo jasné, k čemu se větev vztahuje.<br>
<br>
<br>
<br>
Práce s poli a objekty skrývá další úskalí. Místo řetězení if a else použijte včasné ukončení — tzv. early return. Když funkce začne kontrolou neplatných vstupů a vrátí null nebo prázdnou hodnotu, hlavní logika zůstane na první úrovni odsazení. Vyhnete se tak pyramidám závorek, které se nedají číst. Také místo for cyklů zkuste map, filter a reduce. Tyto metody vyjadřují záměr — transformace, filtrování, agregace — a kód je pak kratší a přehlednější.<br>
<br>
<br>
<br>
Zkuste si osvojit jeden zvyk — při každé úpravě souboru se podívejte, jestli můžete něco zjednodušit. Nemusíte předělávat vše najednou, stačí jedna malá změna denně. Postupně se vám kód stane přirozeně čistším a ušetříte hodiny při ladění. Až příště narazíte na funkci, které nerozumíte po pěti sekundách čtení, víte, co dělat — přejmenujte ji, rozdělte ji nebo ji úplně smažte.
