CSS: oddělte vzhled od struktu
Rozhodovací proces musí být rychlý a jednoznačný. Určete, kdo má právo zastavit nasazení a kdo schvaluje rollback, ať se nikdo nečeká na svolení, které nikdo nedá. Sledujte po nasazení klíčové ukazatele – chybovost, latenci, počet výjimek – a mějte stanovené prahy, při jejichž překročení se automaticky vrací předchozí verze. Bez prahů se chyba řeší dohadováním, zatímco uživatelé vidí rozbitou službu.
Jak psát zprávy, které vydrží Pište v rozkazovacím způsobu: „Přidat testy pro okrajové případy", ne „Přidal jsem testy". Držte se jednoho jazyka – buď čeština, nebo angličtina, ale konzistentně. Nikdy nemíchejte obojí v jednom repozitáři. Vyhněte se obecným slovům jako „věci", „něco", „různé". Pokud commit obsahuje více nesouvisejících změn, rozdělte ho. Malé commity se snáze hledají i vysvětlují.
Základem je popsat, co commit dělá, ne co jste chtěli. Místo „oprava chyby" napište „oprava dělení nulou v parseru". Místo „úprava" napište „přesun validace z modelu do služby". První řádek by měl být krátký, do 50 znaků, a měl by fungovat jako titulek. Pokud potřebujete vysvětlit proč, použijte tělo zprávy oddělené prázdným řádkem. To je místo pro kontext, odkazy na issue nebo vysvětlení okolností.
Rollback musí být nacvičený, ne improvizovaný Rollback plán patří do repozitáře vedle kódu a musí obsahovat konkrétní příkazy pro vrácení aplikace, databázových migrací a cache. U migrací platí zvláštní opatrnost: návrat schématu je často destruktivní, proto migrace navrhujte tak, aby stará i nová verze aplikace chvíli běžely současně. Typická chyba je rollback aplikace bez rollbacku databáze – aplikace nastartuje, ale padá na nekompatibilním schématu. Před každým nasazením si ověřte, že rollback skript skutečně existuje a byl testován na stejném typu prostředí.
Představte si, že za půl roku hledáte, proč se změnilo chování funkce. Otevřete historii a vidíte: „oprava", „update", „ změny". Nic nevíte. Musíte projít každý commit ručně. To je přesně důsledek zpráv, které nic neříkají. Přitom stačí dodržet pár zásad a historie se stane vaším nejlepším nástrojem.
Poslední věc, na kterou se zapomíná: konzistence. Formátování, uvozovky, středníky, pořadí importů. Není důležité, kterou variantu zvolíte, ale to, že ji dodržíte všude. Použijte nástroj, který formátování vynutí automaticky, a nestrávejte čas dohadováním se v revizích. Stejně tak držte jednu úroveň abstrakce v jedné funkci — nemíchejte volání databáze s ručním skládáním řetězců. Čistý kód není cíl, je to vedlejší efekt toho, že při psaní myslíte na toho, kdo ho bude číst po vás.
Mezi nejčastější chyby patří nasazování v pátek odpoledne, rollback bez zálohy dat, spoléhání na to, že někdo „to" zvládne ručně, a chybějící monitoring po návratu. Po rollbacku je nutné ověřit nejen dostupnost, ale i správnost dat a front. Až poté se řeší příčina. Následná analýza má odpovědět na tři otázky: co se změnilo, proč to neodhalily testy a jak se příště zkrátí čas do detekce. Bez ní se stejná chyba vrátí při dalším nasazení.
Volba licence není formalita na konci projektu, ale rozhodnutí, které ovlivní, kdo a jak může váš kód používat. Permisivní licence (MIT, BSD, Apache) dávají uživatelům maximální svobodu — mohou kód použít i v uzavřených produktech, aniž by museli zveřejnit své úpravy. Copyleftové licence (GPL, AGPL) naopak vyžadují, aby každý, kdo šíří odvozené dílo, poskytl zdrojový kód za stejných podmínek. Nejde o ideologii, ale o to, co od svého projektu skutečně chcete.
Produkční chyba po nasazení nové verze není otázkou štěstí, ale připravenosti. Většina týmů, které při rollbacku ztratí hodiny, selhala už před nasazením: neměly verzovaný artefakt, neměly ověřený postup návratu a neměly jasně určeno, kdo rozhoduje o zastavení nasazení. Cílem není rollback nikdy nepotřebovat, ale umět se vrátit do funkčního stavu během minut, ne hodin.
Dávejte pozor na tichá selhání. Porovnávání == přetypovává hodnoty a výsledek bývá překvapivý, proto pište výhradně ===. Funkce, která může selhat, má selhat nahlas: vyhoďte chybu, nebo vraťte jasně rozpoznatelnou hodnotu. Prázdný catch blok chybu spolkne a vy ji budete hledat hodiny. Stejně tak nedávejte do kódu magická čísla a řetězce; pojmenovaná konstanta nahoře v souboru řekne víc než hodnota vnořená uprostřed podmínky.
Typická chyba je zpráva „WIP" nebo „ještě nehotovo". Takový commit ztrácí smysl, jakmile ho dokončíte. Další častá chyba je odkazovat se na číslo úkolu bez popisu – za rok už nebudete vědět, co úkol znamenal. Také se vyhněte zprávám, které jen opakují diff: „změna řádku 5" nikomu nepomůže.