Nejčastější chybou je vybrat licenci podle popularity, ne podle skutečného použití. Když váš projekt používá knihovny s konkrétní licencí, musíte zkontrolovat, jestli jsou navzájem slučitelné. Například kód pod GNU GPL nelze bez dalších opatření kombinovat s kódem pod licencí, která obsahuje další omezení. Před publikováním si projděte závislosti a jejich licence – ideálně pomocí automatického nástroje, který prohledá celý strom závislostí. Pokud některou knihovnu používáte jen interně, neznamená to, že na ni licence nemá vliv.<br>
<br>
<br>
<br>
Při psaní testu se řiď vzorem Arrange-Act-Assert, česky uspořádej-proveď-ověř. Nejdřív připrav testovací data, pak zavolej testovanou metodu a nakonec porovnej výsledek s očekávanou hodnotou. Například u funkce pro výpočet obvodu kruhu bys mohl použít vstup poloměr 5 a očekávat výsledek přibližně 31,4159. Nezapomeň na zaokrouhlení, protože práce s desetinnými čísly může způsobit malé odchylky. Raději porovnávej s tolerancí, než abys spoléhal na přesnou shodu. Tento vzor udržuje test čitelný a každý řádek má jasný účel.<br>
<br>
<br>
<br>
Pro týmovou spolupráci je klíčové, aby každá změna prošla code review. Nikdo by neměl pushovat přímo do hlavní větve, ani když jde o malou opravu. Místo toho vytvořte pull request, ve kterém popíšete, co jste změnili a proč. Recenzent se podívá na změny, případně navrhne úpravy, a teprve poté se změna sloučí. Tento proces není zbytečná byrokracie, ale způsob, jak chytit chyby dřív, než se dostanou do produkce. Zároveň pomáhá šířit znalosti o kódu mezi členy týmu.<br>
<br>
<br>
<br>
DevOps je často mylně chápán jako sada nástrojů nebo pozice, kterou obsadíte jedním specialistou. Ve skutečnosti jde o kulturu spolupráce mezi vývojem a provozem, která má za cíl zkrátit cyklus dodání software a zvýšit jeho stabilitu. Než začnete cokoli instalovat, pochopte, že DevOps začíná u lidí a procesů, ne u technologií. Bez změny přemýšlení vám žádná automatizace nepomůže a výsledkem bude jen drahý a nefunkční systém.<br>
<br>
<br>
<br>
Další praktický bod: jak chcete, aby váš projekt vypadal na GitHubu nebo GitLabu? Důležitý je nejen samotný text licence, ale i hlavičky v souborech. Mít licenci pouze v kořenovém adresáři nestačí, pokud přebíráte kód z více zdrojů. U každého souboru by mělo být jasné, kdo je autorem a pod jakou licencí je zveřejněn. To oceníte hlavně ve chvíli, kdy někdo přijde s připomínkou, že jste porušili cizí práva. Bez hlaviček je dohledávání původu velmi pracné a může vést k právním problémům.<br>
<br>
<br>
<br>
Na závěr si zapamatujte: DevOps není cíl, ale průběžný proces. Neočekávejte, že za dva měsíce budete mít plně automatizovaný provoz. Důležité je, že se váš tým každý týden zlepšuje. Nedávejte si za cíl „zavést DevOps", ale zkraťte dobu od nápadu k produkci o polovinu. Pokud se vám to podaří, automatizace a nástroje přijdou samy jako přirozená součást řešení. Bez toho vše skončí jen jako další neúspěšný projekt.<br>
<br>
<br>
<br>
Na co si dát pozor při výběru a implementaci GraphQL ale není bez nástrah. První z nich je kontrakt na straně serveru – pokud nebudete pečlivě definovat typy a resolvery, snadno vytvoříte nepřehledný chaos, který se obtížně udržuje. Druhým úskalím je ochrana proti příliš hlubokým nebo rozsáhlým dotazům. Jednoduchý útočník může poslat dotaz na tisíce vnořených položek a zahltit server. Musíte proto nastavit limity na hloubku dotazu a velikost odpovědi. REST je v tomto ohledu bezpečnější, protože endpointy mají pevnou strukturu a server kontroluje, co se vrací.<br>
<br>
<br>
<br>
<span style="font-weight: 800;">Výběr prvního</span> programovacího jazyka bývá často ochromený přemírou rad z internetu. Mnozí začátečníci skončí u jazyka, který je nebaví, protože ho zvolili podle popularity, ne podle vlastních cílů. Základní pravidlo zní: nezačínej u technologie, ale u problému, který chceš řešit. Chceš dělat weby, automatizovat nudné úkoly, nebo tvořit hry? Každá oblast má svého přirozeného favorita.<br>
<br>
<br>
<br>
První unit test obvykle vzniká ve chvíli, kdy zjistíš, že ruční zkoušení kódu po každé změně je neúnosné. Než ale otevřeš testovací framework, zastav se u tří základních předpokladů. Test musí být deterministický, rychlý a izolovaný. Deterministický znamená, že při stejném vstupu vždy vrátí stejný výsledek. Izolovaný znamená, že nezávisí na pořadí spuštění nebo na stavu databáze. Rychlost je důležitá, protože pomalý test tě brzy přestane bavit a začneš ho přeskakovat. Pokud tyto tři vlastnosti nemáš, test bude spíš přítěží než pomocníkem.<br>
<br>
<br>
<br>
Když tým přejde na Git, většinou začne s jednoduchým tokem: každý pracuje na vlastní větvi, poté se změny sloučí do hlavní větve. Tento přístup funguje u malých projektů, ale s rostoucím týmem narazíte na konflikty, ztracené změny a nepřehlednou historii. Největší problém nebývá samotný nástroj, ale pravidla, která si tým nestanoví předem. Bez jasných pravidel se i zkušení vývojáři dostanou do situace, kdy nevědí, kam commitnout změnu nebo jak správně provést review.
