Při práci s debuggerem se nebojte použít breakpointy místo tisku proměnných do konzole. Moderní IDE vám umožní procházet kód řádek po řádku, sledovat hodnoty v reálném čase a podmíněně zastavit běh. To je zvlášť užitečné při hledání logických chyb. Zároveň si dejte pozor na automatické formátování: pokud používáte nástroj jako je Black, nastavte jej tak, aby nesahalo do kódu proti vaší vůli. Je lepší formátovat vědomě než nechat IDE měnit strukturu bez vašeho vědomí, což vede ke zbytečným změnám v repositáři.
Naopak GraphQL vyniká tam, kde potřebujete flexibilitu a rychlost vývoje. Jestliže máte složitou doménu s mnoha vzájemně provázanými entitami (např. sociální síť, dashboard s mnoha grafy), GraphQL umožní klientovi získat přesně ta data, která potřebuje, jediným dotazem. To eliminuje problém overfetchingu a underfetchingu — REST při náročnějších požadavcích často donutí klienta volat více endpointů, což zvyšuje latenci a zbytečně zatěžuje server.
Nezapomínejte na časté a malé commity. Každá logicky ucelená změna by měla být samostatným commit s výstižným popiskem. To usnadňuje revizi, ale i případný reverz. Vyhněte se commitům typu „oprava překlepu" – ty patří do předchozího commitu. Ideální je, když každý commit představuje jednu funkcionalitu nebo opravu, kterou lze samostatně nasadit. Tím se snižuje riziko, že při slučování větví vezmete i nechtěné změny.
Důležité je také zvážit, jak se vaše API bude vyvíjet. REST vyžaduje při změně datového modelu často nový endpoint nebo verzi API, což přináší údržbu a zpětnou kompatibilitu. GraphQL vám umožňuje přidávat nová pole do existujícího schématu bez narušení starších klientů. Pokud ale vaše API poskytuje čistě jednoduché CRUD operace, je GraphQL zbytečně složité — jeho schéma a resolvery přidávají vrstvu abstrakce, která se nevyplatí.
Při návrhu API často stojíte před zásadním rozhodnutím: zvolit REST, nebo GraphQL. Neexistuje univerzální odpověď — obě technologie mají své silné i slabé stránky. Klíčem je pochopit, co vaše aplikace skutečně potřebuje, a podle toho se rozhodnout. V tomto článku se zaměříme na konkrétní situace, kdy se vyplatí sáhnout po té či oné variantě.
Růst codebase s sebou nese tlak na rychlost dodávání nových funkcí. Často se ale zapomíná na to, že testy nejsou jen pojistka proti regresím, ale i nástroj, který ovlivňuje rychlost vývoje. Klíčové je najít rovnováhu mezi jednotkovými testy, které testují izolované části kódu, a integračními testy, které ověřují spolupráci komponent. Pokud je poměr špatně, údržba testů začne požírat čas, který by mohl jít do produktu.
Dalším aspektem je doba běhu. Pokud testy trvají déle než pár minut, vývojáři je přestanou spouštět před commitem. Proto rozdělte testy na rychlé (jednotkové) a pomalé (integrační). Rychlé testy spouštějte při každé změně, pomalé až v CI při sestavení pull requestu. Tím zajistíte, že vývojář dostane rychlou zpětnou vazbu, ale zároveň se ověří celková funkčnost systému.
Základní pravidlo je jednoduché: pište jednotkové testy pro logiku, která má jasné vstupy a výstupy, a integrační testy pro kritické cesty, které propojují více vrstev. Typickou chybou je testovat všechno přes integrační testy, protože se zdá, že to lépe simuluje reálné použití. Výsledkem je ale pomalá testovací sada, která při změně jedné závislosti vyžaduje úpravy mnoha testů. Naopak jednostranné zaměření na jednotkové testy vede k tomu, že se přehlédnou problémy vzniklé při propojení modulů.
Jak strukturovat zprávu, aby dávala smysl Praktický postup: první řádek do 50 znaků shrnuje podstatu změny, druhý řádek nechte prázdný a pak pokračujte podrobnostmi. V hlavičce použijte imperativ, jako „přidej validaci e-mailu" nebo „odstraň duplicitní dotaz". Tělo zprávy pak rozveďte – co bylo špatně, proč jste zvolili toto řešení, jaké alternativy jste zvažovali. Vyhněte se ale zbytečným detailům o implementaci, které jsou vidět v kódu.
Častou chybou je psát vágní fráze typu „oprava" nebo „update". Pokud nemáte prostor pro vysvětlení, alespoň upřesněte oblast: „oprava výpočtu daně ve faktuře" je stále lepší než „oprava". Dalším problémem jsou zprávy smíšené – když v jednom commitu řešíte dvě nesouvisející věci. Držte se pravidla jeden commit = jedna logická změna. Pokud to nejde, rozdělte to, i kdyby to mělo znamenat více menších commitů.
Při výběru se také zamyslete nad bezpečností a výkonem. REST má jednodušší ochranu proti SQL injection a snadněji se loguje — každý endpoint je jasně definovaný. GraphQL má tuto výhodu v tom, že umožňuje granulární autorizaci na úrovni polí, ale zároveň riskujete, že klient pošle dotaz, který vedlejším efektem přetíží server (např. vnořené pole, které cyklicky volá databázi). Musíte proto zavést limity na hloubku dotazu a počet vrácených záznamů — to je častý zdroj chyb u začínajících týmů.
