Většina responzivních webů dnes už nestaví layout na plovoucích prvcích, ale na CSS Grid a Flexboxu. Rozdíl mezi nimi není kosmetický: Flexbox je jednorozměrný a řeší rozložení v jedné ose, Grid je dvourozměrný a ovládá řádky i sloupce zároveň. Pokud si to pletete, kód funguje na počítači a rozsype se na telefonu. Začněte tím, že si u každé sekce řeknete, jestli potřebujete zarovnat prvky v řadě, nebo nadefinovat skutečnou mřížku. Teprve pak sáhněte po příslušném nástroji.

Typické chyby: slučování vlastní větve bez aktualizace na hlavní linii, obrovské commity s desítkami nesouvisejících změn, force push do sdílené větve a recenzování vlastního kódu. Každá z nich má stejný důsledek – ztrátu času někoho jiného. Menší commity, častější integrace a jasná domluva fungují lépe než jakýkoli složitý model větvení.

Před nasazením do produkce si nastavte pravidla pro schvalování nových závislostí. Určete, kdo kontroluje licence a jak se řeší výjimky. Vést evidenci nestačí, pokud se seznam neaktualizuje při každé změně. U copyleftových licencí zvažte, zda je výhodnější je oddělit do samostatné komponenty komunikující přes API, nebo je zcela nahradit. U permisivních licencí zase nezapomeňte na povinnost uvádět autory a text licence v dokumentaci produktu.

Nespoléhejte na to, že si každý pamatuje pravidla. Napište je do souboru v repozitáři a odkažte na něj v popisu projektu. Stačí pět až deset bodů: odkud větvit, jak pojmenovávat commity, kdy slučovat, kdo schvaluje. Nový člověk v týmu tak nemusí hádat a vy nemusíte řešit stejné otázky pořád dokola. Pravidla ale musí být krátká, jinak je nikdo nečte.

Výběr prvního programovacího jazyka nezačíná seznamem nejpopulárnějších technologií, ale otázkou, co konkrétně chcete vytvořit. Pokud chcete automatizovat tabulky, upravovat texty nebo zpracovávat data, bude pro vás přínosnější jazyk zaměřený na skriptování a práci s daty. Pokud míříte na webové aplikace, potřebujete jazyk, který zvládne logiku na serveru i propojení s databází. U her a výkonnostních výpočtů hraje roli něco jiného než u webu. Napište si na papír tři konkrétní věci, které chcete do půl roku umět vytvořit, a podle nich zužte výběr na dva kandidáty. Teprve pak hledejte, který z nich se učí lépe.

Hlavní větev držte vždy nasaditelnou. To znamená, že každý commit do ní by měl projít testy a být schopný jít do produkce. Pokud potřebujete práci uložit, ale ještě není hotová, použijte větev nebo koncept, ne hlavní linii. Rozbitá hlavní větev zastaví celý tým – všichni na ní staví a nikdo nemůže bezpečně pokračovat. Oprava se pak dělá pod tlakem a vznikají další chyby.

Typickou chybou je spoléhat na to, že licence je „jen formalita". Ve skutečnosti jde o smluvní podmínky, jejichž porušení může vést k soudnímu sporu nebo k povinnosti zveřejnit vlastní kód. Další častou chybou je zaměňovat open source s public domain. Kód bez licence není volně použitelný, protože chybí výslovné svolení. Stejně problematické je přebírat kód z repozitářů, kde není jasné, kdo je nositelem práv, nebo kde byla licence dodatečně změněna.

Sloučení dělejte přes pull request i v malém týmu. Nejde o byrokracii, ale o to, že druhý pár očí odhalí chyby, které autor přehlédne. V pull requestu popište, co změna dělá a proč, ne jen jak. Recenzent potřebuje vědět, jestli je změna správná, ne rekonstruovat záměr z diffu. Malý pull request do dvou set řádků se recenzuje výrazně lépe než tisícřádkový balík, u kterého se každý jen podepíše, aby měl klid.

Nejdřív si zmapujte, jak dlouho vám code review obvykle trvá. Projděte posledních pět až deset změn, které šly do review. Zapište si, kdy jste je odeslali a kdy přišlo poslední schválení. Získáte reálná čísla místo dojmů. Pokud review běží ve vlnách, změřte i dobu, kdy změna čekala na recenzenta. Právě čekání bývá největší a nejhůř odhadnutelná položka.

Většina týmů se pře o to, jestli používat feature větve, nebo commitovat přímo do hlavní linie. Rozhodnutí není ideologické, ale praktické: záleží na tom, jak často vydáváte, jak velký je tým a jestli máte automatické testy. Pokud testy chybí, trvalá integrace znamená, že rozbitý kód blokuje všechny. Pokud testy máte, přímé commity do hlavní větve výrazně zkracují cestu od nápadu k nasazení.

Začněte tím, že si ke každé vrstvě pyramidy napíšete, co má chránit. U jednotkových testů to bývá logika výpočtů a hraniční stavy, u integračních testů kontrakty mezi službami, u end-to-end testů klíčové uživatelské cesty. Když se požadavek změní, neptejte se nejdřív, jak upravit testy, ale která z těchto ochran se změní. Tím získáte jasný signál, zda jde o úpravu v jedné vrstvě, nebo o přesun odpovědnosti mezi vrstvami.