První práce v IT: chyba, která vás vyřadí už v pohovoru

Větev, commity a testy rozhodují o tempu review Pracuj v samostatné větvi pojmenované podle problému, ne podle svého jména. Jeden pull request má řešit jednu věc. Když do opravy překlepu přimícháš refaktoring, reviewer bude mít dvě nezávislé diskuse v jednom vlákně a pravděpodobně požádá o rozdělení. Commity piš po malých logických celcích a do zprávy napiš, co a proč se mění. Styl se řiď projektem, ne svými zvyky. Pokud projekt vyžaduje podpis commitů nebo konkrétní formát zprávy, nastav si to před prvním commitem.

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á.

Největší chyba vzniká hned na začátku: tým si vybere NoSQL podle popularity a pak se snaží dotazovat stejně jako v relační databázi. Jenže bez schématu se data snadno rozutečou do mnoha podob a každý dotaz začne skenovat celé kolekce. U dokumentových databází to znamená, že dokumenty rostou do obrovských struktur, které se špatně aktualizují, a u key-value úložišť se zase zvětšuje počet požadavků, protože chybí vhodné seskupení. Výsledkem je vyšší latence a složitější provoz, ne rychlejší aplikace.

Typické chyby vznikají v detailech. Datum bez uvedení časového pásma a formátu, čísla jako řetězce, prázdné pole místo chybějící hodnoty, rozdílné názvy polí mezi seznamem a detailem. Frontend pak řeší obchvaty a backend se diví, proč se data zobrazují špatně. Sepište si proto jednotný slovník názvů a typů a držte se ho napříč celým API. Když se něco změní, změňte i dokumentaci a oznamte to.

Před odesláním spusť testy, které projekt používá, a to i ty, které se týkají jen okrajových případů. Přidej vlastní test k opravě — bez něj reviewer nemá jak ověřit, že se chyba nevrátí. Zkontroluj, že kód projde automatickou kontrolou stylu a že v diffu nejsou omylem přidané soubory, lokální konfigurace nebo vygenerované artefakty. Právě tyhle detaily zdrží sloučení nejvíc.

První krok je oddělit odhad od závazku. Když zákazník chce termín, řekněte nahlas, co ten termín znamená: „Tohle je můj odhad za předpokladu, že dostanu podklady do středy a nikdo nezmění zadání." Tím se z odhadu stává podmíněný výrok, ne příslib. Zákazník pak ví, co se musí stát, aby termín platil, a vy máte páku, když se podmínky změní. Bez této věty se každý posun termínu jeví jako vaše selhání.

Po odeslání sleduj vlákno a reaguj věcně. Recenze není útok na tvoji práci. Když s návrhem nesouhlasíš, vysvětli důvod a nabídni alternativu. Pokud projekt na pull request nereaguje déle než dva týdny, slušně se připomeň v komentáři; nezavírej a neotvírej nový. Trpělivost a ochota upravit patch podle připomínek jsou dovednosti, které v open source váží víc než počet řádků.

Popis pull requestu piš jako krátkou zprávu pro člověka, který o problému nic neví. Vysvětli, co bylo špatně, jak to opravuješ a jaké má změna dopady. Odkaž na související diskusi, ale nespoléhej na to, že si ji reviewer přečte. Když si nejsi jistý, napiš to do popisu a označ konkrétní místo v kódu. Otevřenost k připomínkám zkracuje review víc než dokonalý kód.

Začni vissue trackeru. Přečti si, jak projekt označuje chyby a nápady. Hledej štítky jako „good first issue" nebo „help wanted" — existují právě proto, aby nováčkům někdo potvrdil rozsah. Pokud takový štítek chybí, napiš krátký komentář s návrhem řešení a počkej na reakci. Teprve pak se pusť do práce. Přeskočení tohoto kroku je nejčastější důvod, proč je pull request zamítnutý ještě před přečtením kódu.

Kdy NoSQL dává smysl a kdy ne NoSQL použijte tam, kde je přirozeně hierarchický nebo nepravidelný obsah, kde se mění podoba záznamů a kde potřebujete horizontální škálování zápisu. Typicky jde o katalogy s různými atributy, telemetrii, uživatelské profily, události nebo vztahy v grafech. Naopak pro silně transakční agendu s mnoha vzájemně provázanými tabulkami, složitými joiny a požadavkem na okamžitou konzistenci je relační databáze stále bezpečnější volba. Není to ideologie, ale otázka přístupového vzoru.

Před nasazením si napište seznam pěti až deseti nejčastějších dotazů a odhadněte, kolik dat budou číst a zapisovat. Podle toho navrhněte klíče a seskupení dokumentů tak, aby jeden dotaz sáhl na co nejmenší počet míst. U dokumentových databází pomáhá vnořovat data, která se čtou společně, ale zároveň hlídat velikost dokumentu. U grafů zase dávejte pozor na superuzly s obrovským počtem vazeb, které zdržují procházení. Bez tohoto kroku skončíte s pomalými dotazy i na výkonném clusteru.