Když se rozhodnete přispět do open source, nejčastější chybou není nedostatek znalostí, ale špatný start. Místo abyste se vrhli na první issue, které uvidíte, začněte prozkoumáním projektu. Přečtěte si soubor s pokyny pro přispěvatele, pokud existuje. Většina větších projektů má jasně daná pravidla, jak vypadá dobrý pull request, jak psát commit messages a jaké testy se spouští. Bez této znalosti riskujete, že vaše práce bude zamítnuta, i když je technicky správná.
Při psaní kódu dodržujte styl, jaký projekt používá. Pokud má projekt linter nebo formátovač, spusťte ho před odesláním. Typická chyba je, že přispěvatel napíše funkční kód, který ale neodpovídá zvyklostem projektu — používá jiné uvozovky, jiné odsazení nebo pojmenování proměnných. To pak vede k vlně komentářů, které se týkají stylu, ne obsahu. Než odešlete pull request, znovu si projděte změny, spusťte testy a opravte všechny chyby. Pull request by měl být malý, srozumitelný a měl by obsahovat jen změny související s daným úkolem.
Druhým častým problémem je špatné používání HTTP stavových kódů. Mnoho vývojářů vrací při validační chybě kód 200 s chybovou hláškou v těle odpovědi. To je matoucí a porušuje to základy HTTP protokolu. Pro chybějící parametr použijte 400, pro neautorizovaný přístup 401 a pro zakázanou akci 403. Teprve když klient vidí správný stavový kód, může na chybu adekvátně reagovat. Navíc si snadno nastavíte logger, který zaznamená všechny 4xx a 5xx odpovědi pro pozdější analýzu.
Jednotkové testy běží rychle, izolovaně a přesně ukazují, kde se něco rozbilo. Integrační testy sice pokrývají více vrstev, ale jejich provoz je nákladný na čas i údržbu. S rostoucí kódovou základnou přestává být volba mezi nimi otázkou preference – stává se z ní ekonomika zpětné vazby. Čím větší projekt, tím důležitější je vědět, kterou vrstvu test pokrývá, a hlavně kdy jeho přidání přinese víc užitku než bolesti.
Při práci na více větvích souběžně je klíčové časté slučování hlavní větve do vaší feature větve. Nečekejte až na konec, ale průběžně si do své větve natáhněte nejnovější změny od kolegů. Tím minimalizujete rozsah konfliktů, protože rozdíly mezi větvemi řešíte po malých dávkách. Mějte na paměti, že konflikt při sloučení není chyba, ale běžná součást práce. Když k němu dojde, otevřete dotčené soubory a rozhodněte, kterou verzi zachováte. Pravidlem je nespěchat a vždy si přečíst obě strany změny, abyste neztratili důležitou logiku.
Praktický postup pro vyvážení vypadá takto: nejprve si definujte, které části kódu jsou stabilní a kritické – tam integrační testy nasaďte a chraňte je. Pro nestabilní a rychle se měnící části nechte jen jednotkové testy, které pokrývají klíčové scénáře. Zavedte si pravidlo, že každý nový integrační test musí být odůvodněný – pokud nenacházíte konkrétní chybu, kterou by jednotkový test neodhalil, nepřidávejte ho. A hlavně pravidelně měřte dobu běhu a počet testů, které selhávají bez souvislosti se změnami v kódu.
Po odeslání pull requestu očekávejte zpětnou vazbu, ať už pozitivní, nebo negativní. Není to osobní útok — code review je standardní proces. Reagujte na komentáře věcně, vysvětlujte svá rozhodnutí a nezdráhejte se klást otázky, pokud něčemu nerozumíte. Pokud vaše změny neprojdou, nevzdávejte to. Analyzujte, co bylo špatně, a zkuste to znovu s jiným úkolem. Každý pokus vás posune dál a příští příspěvek bude kvalitnější. To je celé tajemství úspěšného zapojení do open source.
Při práci s databází se často zapomíná na validaci vstupů na úrovni API. Express sám o sobě žádnou validaci nenabízí, proto je vhodné použít nějakou knihovnu pro schémata. Pokud validaci podceníte, riskujete neočekávané chyby databáze, které se pak těžko debugují. Vždy si ověřte, že příchozí data odpovídají očekávanému typu a délce. A pokud narazíte na neplatný vstup, okamžitě vraťte 400 s konkrétní chybovou hláškou.
Při návrhu REST API v Node.js s Expressem se většina vývojářů soustředí na správné routy, middleware a databázové dotazy. Mnohem méně pozornosti už věnuje konzistenci odpovědí a chybovým stavům. Přitom právě tato oblast rozhoduje o tom, jak dobře bude vaše API použitelné pro frontendové aplikace i třetí strany. Bez jednotné struktury odpovědí se každý nový endpoint stává noční můrou při integraci.
Častou chybou je také synchronní zpracování asynchronních operací. Pokud v Express handleru zapomenete na async/await nebo na návrat Promise, může dojít k neošetřené chybě, která se projeví až později. Vždy obalujte asynchronní operace do try-catch bloků nebo použijte wrapper pro async routy. Tím zajistíte, že případná chyba bude předána error middleware a klient dostane korektní odpověď. Jinak riskujete tiché selhání nebo spadnutí celého procesu.
