Jednotná konfigurace týmu: co hrozí, když ji nemáte
Jeden terminál nestačí, spouštějte úlohy podle jazyka Terminál a buildovací úlohy jsou třetí místo, kde se více jazyků sráží. Místo jednoho univerzálního skriptu si definujte samostatné úlohy pro každý jazyk a spouštějte je přes přiřazené klávesové zkratky. Pomůže i oddělení virtuálních prostředí nebo správců závislostí — jedno pro každý jazyk. Pokud používáte monorepo, nastavte si pracovní prostory tak, aby editor načetl jen relevantní části projektu podle toho, na čem právě pracujete.
Více jazyků v jednom repozitáři vypadá jako maličkost, dokud nezačnete přepínat mezi soubory a editor přestane rozumět tomu, co vlastně píšete. Klíčové je nastavit prostředí tak, aby každý typ souboru měl přiřazený správný jazyk a nástroje. Většina editorů dnes podporuje rozšíření pro jednotlivé jazyky, ale automatická detekce podle přípony selhává u souborů jako .h, .m nebo šablon s vloženými bloky. Ruční mapování přípon na konkrétní jazyk je první krok, který odstraní většinu zbytečného zvýrazňování a chybových podtržení.
Kdy se z užitečné metriky stává pa
Častou chybou je spoléhat na escapování znaků ručně. Funkce pro úpravu řetězců se liší podle databáze i podle kódování a snadno se na některý znak zapomene. Escapování může být nouzové řešení ve starším kódu, ale nikdy by nemělo být hlavní strategií. Stejně tak nestačí kontrolovat jen délku nebo typ vstupu. Útočník může poslat platné číslo, které však v kontextu dotazu způsobí nečekaný výsledek.
Nejčastější chybou je snaha nastavit všechno ručně v uživatelském profilu. Takové nastavení se rozbije při prvním přechodu na jiný počítač nebo při aktualizaci editoru. Druhou častou chybou je ignorování pořadí, v jakém se rozšíření načítají. Když dvě rozšíření tvrdí, že vlastní stejnou příponu, vyhrává to, které se načte později, a výsledek je nepředvídatelný. Řešením je explicitní priorita nebo vypnutí konfliktního rozšíření pro daný typ souboru.
Zásadní je vybrat nástroj, který tým skutečně používá, ne ten, který je nejmodernější. Pokud někdo pracuje v editoru, který formátování nepodporuje, můžete mít sebelepší konfiguraci, ale stejně se neprosadí. Proto je lepší začít malým společným základem: jeden soubor pro závislosti, jeden pro nastavení prostředí, jeden pro formátování. Ostatní ať zůstane na individuální volbě. Tím se sníží tření a zvýší šance, že konfiguraci budou lidé dodržovat i po měsíci.
Když po roce zjistíš, že se neposouváš, nečekej na zázrak. Promluv si s vedoucím, navrhni konkrétní změnu: pravidelné review, jiný projekt, stínování zkušenějšího kolegy. Pokud se nic nezmění do dvou měsíců, začni se dívat jinam. První práce není manželství. Je to místo, kde si stavíš základy. A základy se mají stavět tam, kde ti někdo ukáže, jak se to dělá.
Druhým krokem je izolace nástrojů. Formátovač, linter a jazykový server pro každý jazyk by měly být nastaveny zvlášť, ideálně přes konfigurační soubory v projektu, ne globálně v editoru. Globální nastavení se často perou mezi sebou — Python formátovač přepíše YAML, JavaScriptový linter křičí na TypeScript. Projektová konfigurace zajistí, že každý člen týmu dostane stejné chování bez ohledu na to, jaký editor používá.
Typická chyba je dlouhé držení větve bez kontaktu s hlavní linií a řešení konfliktů až v pull requestu. Další je rebase veřejné větve, po kterém kolegové dostanou chybu při pullu. Třetí je slepé merge bez kontroly, co se skutečně sloučilo. Po každém rebase nebo merge spusť testy a projdi diff, ne jen commit zprávu. Automatické sloučení může tiše přepsat logiku, kterou jsi nechtěl měnit.
Rebase nebo merge a kdy co použít Pro udržení čisté historie používej rebase lokálně, dokud větev nikdo jiný nepoužívá. Příkaz git rebase main přenese tvé commity na aktuální špičku hlavní linie a odstraní zbytečné merge commity. Jakmile ale větev sdílíš s kolegou, rebase přepíše historii a způsobí ostatním problémy. V tu chvíli je bezpečnější běžný merge. Pravidlo je jednoduché: rebase pro soukromé větve, merge pro veřejné.
Nakonec si nastav rytmus: ráno rebase proti hlavní linii, během dne commity po malých celcích, večer push. Větev, která přežije déle než týden, rozděl nebo znovu založ z aktuálního mainu. Efektivita nevzniká z počtu větví, ale z toho, že každá z nich zůstává malá, aktuální a rychle sloučitelná.
Základem je krátká životnost větve. Feature, která trvá déle než dva tři dny, by měla být rozdělena na menší logické celky, případně skryta za feature flag. Větev vytvářej vždy z aktuálního stavu hlavní linie, ne z jiné rozdělané větve. Pokud to jde, drž v jedné větvi jednu věc. Míchání refaktoringu, opravy chyby a nové funkce v jednom commitu znamená, že při konfliktu nemáš šanci poznat, co má přednost.