Nejčastější chybou je, že si tým neujasní, kdy a jak často se má větvení provádět. Nedoporučuji vytvářet větev pro každou drobnost, ale ani držet všechny změny v jedné dlouhé větvi. Dobrý kompromis je větev na jeden úkol, který má jasný začátek a konec. Před začátkem práce si vždy aktualizujte hlavní větev a vytvořte novou z jejího aktuálního stavu. Vyhnete se tak konfliktům, které vznikají z toho, že pracujete na staré verzi.
Příklady jsou důležitější než popis parametrů Místo strohého seznamu atributů uveďte konkrétní příklad požadavku a odpovědi. Ukažte reálný JSON, ideálně s hodnotami, které odpovídají skutečným datům – ne „string”, ale „název produktu”. Přidejte i příklad chybové odpovědi, ať frontend ví, co má očekávat. Dobře funguje i krátký úryvek volání z javascriptu, ale bez nadbytečných knihoven – stačí fetch s hlavičkami. Tyto příklady by měly být kompletní a zkopírovatelné, aby si je vývojář mohl rovnou vložit do konzole a vyzkoušet.
Nakonec si položte dvě otázky: co chce umožnit uživatelům s vaším kódem a co chcete vidět zpět? Pokud odpovíte „chci, aby mohl každý kód využít, ale s povinností šířit změny pod stejnou licencí”, pak je GPL jasná volba. Pokud chcete maximální šíření bez podmínek, sáhněte po MIT. Rozhodnutí není nevratné – licence můžete změnit, ale jen v rámci budoucích verzí a s rizikem fragmentace komunity. Proto si dejte na výběr čas a konzultujte to s právníkem, pokud máte pochybnosti.
Základním kamenem je sdílená hlavní větev, obvykle nazývaná main nebo master. Nikdo by do ní neměl commitovat přímo. Místo toho si každý vytvoří vlastní větev z aktuálního stavu hlavní větve, pracuje na ní a změny začlení až po kontrole. Tím se oddělí nedokončená práce od stabilního kódu. Pokud někdo potřebuje rychle opravit chybu, může vytvořit samostatnou větev, která se po začlenění smaže. To udržuje historii čitelnou a přehlednou.
Další pravidlo, které pomáhá, je časté začleňování změn do hlavní větve. Pokud máte větev otevřenou déle než dva dny, začleňte ji. Dlouhé větve totiž vedou ke konfliktům, které se pak řeší hodiny. Méně zkušeným kolegům to může připadat jako zdržení, ale ve výsledku je to rychlejší, než po týdnu slučovat stovky změn. Pokud narazíte na konflikt, nesnažte se ho vyřešit přímo v prohlížeči. Stáhněte si změny do lokálního prostředí, podívejte se na rozdíly a slučte ručně.
Další praktickou věcí je verzování a označení změn. Pokud dokumentaci aktualizujete, nepište jen nový obsah, ale zvýrazněte, co se změnilo – ať už přidáním pole, změnou typu nebo úpravou chování. Frontend pak rychle najde, co se ho týká, a nemusí pročítat celou dokumentaci. Vhodné je i uvádět datum poslední změny nebo číslo verze API. Tím se vyhnete situaci, kdy si frontend myslí, že používá starou verzi, a backend už mezitím nasadil novou.
V praxi to znamená, že většinu testů píšete na úrovni jednotek — malé a izolované testy, které ověřují jednu třídu nebo funkci. Nad nimi jsou integrační testy, které kontrolují spolupráci mezi komponentami, a na vrcholu end-to-end testy procházející celou aplikací. Typická chyba začátečníků je obrátit pyramidu vzhůru nohama: spoléhat se hlavně na UI testy, které jsou pomalé, křehké a při sebemenší změně selektoru selhávají. Výsledkem je sada testů, která běží hodiny a většinu času jen křičí falešné poplachy.
Základem je jednotné schéma odpovědí. Pokud každý endpoint vrací jinou strukturu – někdy objekt, jindy pole pod jiným klíčem – je to první zdroj chaosu. Domluvte se na společném obalu, třeba na objektu s poli pro data, chybu a metadata. Tento obal pak používejte všude. Do dokumentace zapište, že každá úspěšná odpověď má tvar data: … a každá chyba error: code, message . Frontend si pak napíše jednu univerzální funkci na zpracování odpovědí a nemusí řešit výjimky pro každý endpoint zvlášť.
Když backend dodá rozhraní bez pořádné dokumentace, frontend vývojář stráví hodiny hádáním, co přesně endpoint přijímá a vrací. Výsledkem jsou zbytečné opravy, přepisování kódu a třecí plochy mezi týmy. Přitom stačí dodržet pár konkrétních pravidel, která práci s API změní z věštění na rutinu. Nejde o psaní románů, ale o strukturu, příklady a jasné definice – přesně to, co frontend potřebuje, aby mohl fungovat samostatně.
Výběr open source licence bývá často podceňovaným krokem. Mnoho vývojářů soustředí veškerou energii na kód a architekturu, ale licenci odbude pětiminutovým rozhodnutím. Přitom právě licence určuje, kdo a jak může váš software používat, upravovat a šířit. Chybná volba přitom může vést k tomu, že se z vašeho projektu stane proprietární nástroj, nebo naopak že ztratíte kontrolu nad komerčním využitím. Než začnete s distribucí, je nutné si ujasnit, co od sdílení kódu vlastně očekáváte.
