Poslední věc je výkon. Když má IDE indexovat všechny jazyky najednou, zpomalí se start i našeptávání. Vyluč z indexování buildovací složky, cache a vygenerované soubory. Pokud to jde, zapni jazykové servery jen pro jazyky, na kterých právě pracuješ. Pravidelně kontroluj, jestli některý plugin neběží naprázdno. Rozdělení jazykových vrstev a jasná pravidla v repozitáři ti ušetří víc času než jakákoli zkratka v editoru.

U rozsáhlejších projektů oceníš skok na definici a zpět. Otestuj to na cizí knihovně, ne jen na vlastním kódu. Prostředí, které neumí dohledat definici v nainstalovaném balíčku, ti při ladění moc nepomůže. Stejně tak si ověř, jak zvládá velké soubory. Otevři soubor s několika tisíci řádky a zkus v něm hledat. Zamrzání při každém stisku klávesy je signál, že dané prostředí není pro tvůj styl práce vhodné, i kdyby mělo sebelepší vzhled.

Začni tím, že oddělíš jazykové vrstvy na úrovni projektu, ne na úrovni editoru. V kořeni vytvoř konfigurační soubory, které patří jednotlivým jazykům: lint konfiguraci pro Python, tsconfig pro TypeScript, formatter pro Javu. IDE pak nemusí hádat, co je co. Typická chyba je jedna globální konfigurace, která se snaží obsáhnout všechno. Výsledkem je, že formátovač přepíše cizí soubor podle špatných pravidel a ty to zjistíš až v review.

Rozvržení se dnes nedělá pomocí tabulek ani plovoucích prvků, ale pomocí mřížky a flexboxu. Flexbox stačí na řazení prvků vedle sebe nebo pod sebe, mřížka zvládne složitější rozvržení se sloupci a řádky. Oba nástroje jsou součástí CSS a nepotřebujete k nim žádnou knihovnu. Kdo je zvládne, obejde se bez zbytečných závislostí a jeho stránky se načtou rychleji.

Dále nastav jazyk souborů ručně pro formáty, které jsou nejednoznačné. Soubory jako .h, .m nebo šablony s více syntaxemi editor často zařadí špatně. Přepni jazyk konkrétního souboru a případně si ulož pravidlo podle přípony nebo cesty. Pomůže i to, že si v projektu vytvoříš složky podle jazyka a ne podle funkce. Strom, kde je Java, Python a TypeScript promíchaný v jedné složce, nutí IDE i tebe neustále přepínat kontext.

Prvním krokem je určit, kdo je autorem a kdo drží práva. U firemních projektů platí, že práva zaměstnanců přecházejí na zaměstnavatele jen tehdy, pokud je to smluvně ošetřeno. U externích spolupracovníků je nutné mít písemné přiřazení práv, jinak nemáte oprávnění licence udělovat. Teprve poté má smysl řešit, kterou licenci zvolit.

Praktické rozhodnutí: začni RESTem, dokud máš pod deset hlavních zdrojů a klientů je málo. Až začne přibývat variant odpovědí, zvaž GraphQL jako bránu před existující služby. Nemusíš přepisovat vše. Nech REST pro zápisové operace a jednoduché čtení, GraphQL nasaď pro složité čtecí scénáře. Vždy měř dobu odpovědi, počet dotazů do databáze a velikost přenášených dat. Právě tato čísla ukážou, jestli se změna vyplatila.

U GraphQL se také mění práce s cache. HTTP cache na úrovni URL zmizí, protože vše jde na jeden endpoint přes POST. Řešením je persistované dotazy, cache na úrovni resolverů nebo dedikovaná vrstva. Pokud tým nemá kapacitu na monitoring a optimalizaci dotazů, bývá REST levnější na provoz i na údržbu. Naopak pokud klienti neustále žádají nové kombinace polí, REST se zvrhne v desítky účelových endpointů a GraphQL je čistší.

Nezapomínej na ladicí běh. Nastav breakpoint, spusť program a zkontroluj, jestli vidíš hodnoty proměnných v okamžiku zastavení. Některá prostředí vyžadují doplňkový konfigurační soubor, jiná fungují okamžitě. Pokud ladění vyžaduje ruční zápis konfigurace, je to přijatelné, ale jen když rozumíš každému řádku. Zkopírovaná konfigurace bez pochopení bývá častým zdrojem chyb, které se projeví až za běhu.

Poslední rada: vyber si prostředí, které zvládneš ovládat klávesnicí. Můžeš mít sebelepší doplňování, ale pokud kvůli každé operaci saháš po myši, přicházíš o čas i soustředění. Nauč se pět klávesových zkratek pro pohyb mezi soubory, hledání v projektu a spuštění testů. Teprve pak zvažuj rozšíření. Prostředí, které ti sedne, poznáš podle toho, že po týdnu používání přestaneš přemýšlet nad tím, jak je ovládat.

Poslední věc, na kterou se zapomíná: domluvte se na jednom stylu commit zpráv a držte se ho. Krátký souhrn v rozkazovacím způsobu a v těle vysvětlení proč, ne co. Historie, ze které se dá číst, je pro tým cennější než jakýkoli nástroj nad ní. A když se pravidla přestanou hodit, změňte je společně a napište to do repozitáře. Jediné skutečně špatné pravidlo je to, o kterém si každý myslí něco jiného.