Jak větvit kód, aby se změny nepozabíjely

Práce na více feature větvích současně je běžná realita, ale bez pravidel se během pár dní změní ve zmatek, kde nikdo neví, co je hotové a co rozpracované. Základem je krátká životnost větve. Feature branch by měla žít hodiny až dny, ne týdny. Čím déle větev existuje, tím větší je vzdálenost od hlavní linie a tím bolestnější je její sloučení. Prakticky to znamená rozdělit práci na malé celky, které jdou dokončit a sloučit nezávisle na sobě.

Filtrování navrhujte jako sadu pojmenovaných parametrů, ne jako univerzální jazyk. ?status=active&created_after=2024-01-01 je čitelné, testovatelné a snadno se mapuje na indexy. Vyhněte se parametru typu ?q=status:active AND price>100, pokud k tomu nemáte skutečný důvod – otevíráte tím cestu k injekcím a neplánovaným full scanům. U každého filtru si předem napište, který index ho pokryje. Pokud filtr kombinuje více sloupců, zvažte složený index v pořadí, v jakém se podmínky skutečně používají.

Náboráři a techničtí leadové tráví u jednoho životopisu méně než minutu. Pokud v něm není vidět, co kandidát reálně postavil, končí. Proto dej odkazy na repozitáře hned nahoru, ne na konec. U každého projektu uveď jednu konkrétní věc, kterou sis musel nastudovat sám, a jednu, kterou bys dnes udělal jinak. Tím ukazuješ schopnost reflexe, což je v juniorské pozici cennější než znalost syntaxe nazpaměť.

Mezi časté chyby patří vracení celkového počtu záznamů u každého požadavku. COUNT(*) nad miliony řádků zdrží odpověď klidně o sekundy a klient ho většinou nepotřebuje. Nabízej ho jako samostatný endpoint nebo vůbec. Další chybou je neomezená velikost stránky – bez stropu (například 100 položek) si někdo vyžádá celou tabulku a shodí ti databázi. A třetí: řazení podle sloupce, který není v indexu, což u kurzorového stránkování způsobí, že se dotaz zpomalí stejně jako offset.

Dále si hlídejte mutace. JavaScript dovoluje měnit objekty předávané do funkcí, což snadno vede k nečekaným vedlejším efektům. Pokud funkce nemá měnit vstup, pracujte s kopií nebo použijte čistý přístup, kdy funkce vrátí novou hodnotu a původní nechá být. U polí a objektů se vyhněte přímému zápisu do parametru, pokud to není záměr.Čistý kód také znamená, že se funkce chová stejně při stejném vstupu, bez ohledu na pořadí volání.

U open source licencí rozhoduje, zda jde o permisivní, nebo copyleftovou licenci. Permisivní licence obvykle vyžadují zachování autorských práv a textu licence, ale nezasahují do licencování vašeho kódu. Copyleftové licence mohou vyžadovat, aby byl odvozený kód šířen pod stejnou licencí. U síťových licencí vzniká povinnost i při pouhém provozu služby. Rozdíl je zásadní pro to, co můžete klientovi dodat a co si nechat interně.

Čistý kód v JavaScriptu není o estetice, ale o tom, aby se v něm dalo rychle najít problém a bezpečně měnit chování. Největší zdroj zmatku bývají funkce, které dělají příliš mnoho věcí najednou. Pokud funkce načítá data, upravuje je, zapisuje do globálního stavu a ještě mění DOM, každá změna je riskantní. Rozdělte ji na menší celky, z nichž každý má jednu odpovědnost. Konkrétně: pojmenujte funkci podle toho, co vrací nebo jaký stav vytváří, a pokud název obsahuje spojku „a" (například „nactiAUprav"), je to signál k rozdělení.

Typické chyby: smazání hlaviček s autorskými právy, sloučení kódu pod jinou licencí bez kontroly, použití knihovny s copyleftem v uzavřeném produktu nebo vydávání cizího kódu za vlastní. Další častou chybou je spoléhat na to, že licence je jen formalita. Pokud si nejste jistí výkladem, konzultujte právníka specializovaného na duševní vlastnictví, ne kolegu od vedle.

Nezapomínejte na chybové stavy. Kód, který předpokládá, že všechno projde, je křehký. Místo tichého `undefined` použijte raný návrat nebo vyhození chyby s jasnou zprávou. Kontrolujte vstupy na začátku funkce, ne uprostřed. Tím se hlavní logika odsadí a čte se jako příběh. Zároveň se vyhněte hlubokému vnořování podmínek; častěji pomůže obrácená podmínka a návrat.

Pojmenování a předvídatelnost Názvy proměnných a funkcí mají odpovídat tomu, co drží. Vyhněte se zkratkám jako `tmp`, `data2` nebo `x`, pokud nejde o krátký matematický výraz. U booleanů používejte předpony `je`, `ma`, `muze` — čtenář pak nemusí dohledávat, co znamená `true`. Stejně tak se vyhněte „magickým" hodnotám. Číslo 7 v podmínce nic neříká; konstanta `MAX_POKUSU = 7` řekne vše. Když se hodnota používá na více místech, patří do jedné konstanty, jinak při změně zapomenete na jednu z kopií.

Kdy je kód klienta opravdu jeho a kdy ne Klient může tvrdit, že kód napsal, ale část mohla vzniknout jako dílo zaměstnanců, dodavatelů nebo z jiného projektu. Ptejte se proto konkrétně: kdo kód vytvořil, na základě jaké smlouvy a zda existují výjimky. Bez písemného potvrzení o původu a právech kódu nemá smysl řešit licence jednotlivých souborů. Pokud klient potvrzení nedá, berte kód jako rizikový a jeho použití omezuje na minimum.