Co rozhoduje o tom, že první práce v IT vyjde?

Na pohovoru se neboj přiznat, co neumíš. Vymyšlená znalost se odhalí za dvě otázky a mnohem víc bolí než přiznaná mezera. Ptej se taky ty: jak vypadá code review, kdo zaškoluje nováčky, kolik času je vyhrazeno na učení. Odpovědi prozradí víc než inzerát. Pokud firma nemá odpověď na to, kdo tě zaučí, budeš první měsíce tápat sám.

Nakonec dbejte na čistotu testů. Po každém testu obnovte mocky a vyčistěte stav, aby se chyby nepřenášely mezi testy. Používejte `beforeEach` a `afterEach`. Pokud test závisí na pořadí, je to signál, že není izolovaný. Dodržováním těchto postupů pokryjete většinu logiky Reduxu bez potřeby integračního prostředí a zkrátíte zpětnou vazbu na minimum.

Asynchronní akce bez sítě a prohlížeče U async akcí (thunk, saga, observable) je klíčové oddělit orchestraci od samotného volání API. Místo skutečného fetch volání použijte mock. Například u thunků vytvořte fake dispatch a getState, a do thunku injektujte závislosti. Pokud thunk volá `fetch` přímo, mockněte globální `fetch` nebo použijte knihovnu jako `jest-fetch-mock`. U sag používejte `redux-saga-test-plan` nebo ruční testování generátorů – stačí projít jednotlivé kroky a porovnat vydané akce. U observable použijte `TestScheduler` z RxJS.

Každý, kdo někdy plánoval práci na softwarovém úkolu, zná ten pocit: odhad je hotový, termín zapsaný, a pak přijde code review a připomínky. Najednou je vše jinak. Přitom stačí málo – systematicky do odhadu zahrnout i čas na revizi a zapracování připomínek. Nejde o žádnou vědu, ale o návyk, který se vyplatí pěstovat od prvního ticketu.

Základem je rozdělit si práci na fáze a každé přiřadit reálný čas. Samotné psaní kódu bývá jen polovina celkové práce. Zbytek tvoří příprava, testování, čekání na review, čtení komentářů a jejich zapracování. Pokud odhadujete jen „čisté" programování, výsledek bude vždy podhodnocený. Praxe ukazuje, že review a následné úpravy zaberou klidně třetinu až polovinu času stráveného psaním kódu. U složitějších změn nebo v týmu, kde je review důkladné, to může být i více.

Kdy přesunout test do jiné vrst

Dále sledujte, jak prostředí zvládá velké soubory a rychlé přeskakování mezi definicemi. Otevřete projekt s několika tisíci souborů a zkuste vyhledat symbol nebo přejít na definici funkce. Pokud odezva trvá déle než zlomek sekundy, budete práci odkládat. Některá prostředí nabízejí indexaci na pozadí; u velkých projektů je vhodné nastavit, které složky ignorovat, například virtuální prostředí, cache nebo výstupy testů.

Začni tím, že si vybereš jednu technologii a u ní zůstaneš alespoň půl roku. Typická chyba je skákat z jazyka do jazyka podle toho, co zrovna frčí v diskusích. Zaměstnavatel nepozná, jestli umíš málo, nebo hodně, ale pozná, jestli umíš něco dotáhnout. Jeden web s přihlášením, databází a nasazením na veřejnou adresu řekne o tvých schopnostech víc než kurz s certifikátem.

Repozitář s konfigurací bývá citlivější než ten s kódem. Rozdělte ho podle prostředí, například na větve nebo samostatné složky pro vývoj, staging a produkci. Do repozitáře nepatří hesla, tokeny ani privátní klíče. Ty držte mimo verzovací systém, ideálně v nástroji na správu tajemství nebo v proměnných prostředí, které se vkládají až při nasazení. Pokud už tajemství v historii máte, nestačí je smazat v dalším commitu. Musíte je rotovat a historii přepsat, jinak zůstanou dostupná komukoli, kdo si repozitář naklonuje.

Prostředí nemusí být jen jedno. Mnoho vývojářů kombinuje lehký editor pro rychlé úpravy a plnohodnotné IDE pro větší refaktoring. Důležité je, aby obě strany používaly stejná pravidla formátování a stejný interpret. Jinak se dříve nebo později objeví rozdíly, které zdržují. Vyberte si tedy podle toho, jak skutečně pracujete, ne podle seznamu funkcí.

Statická analýza a formátování jako součást prostředí Dobré prostředí podporuje nástroje pro kontrolu kódu a formátování, ale nemělo by je vnucovat bez možnosti vypnutí. Nastavte si, zda se má kód formátovat při uložení, nebo až na vyžádání. Typická chyba je zapnout formátování při každém uložení u projektu, kde tým používá jiný styl. Výsledkem jsou obrovské rozdíly v gitu a zbytečné konflikty. Před zapnutím automatických úprav si přečtěte konfiguraci projektu a sjednoťte pravidla s ostatními.

Pro ověření integrace mezi reducerem a async akcí můžete použít skutečný store, ale bez UI. Vytvořte store s reálnými reducery a middleware, dispatchněte async akci a počkejte na dokončení. Poté zkontrolujte výsledný stav. Tím odhalíte chyby v propojení, aniž byste spouštěli prohlížeč. Vždy ale izolujte síťové volání – nahraďte ho mockem, který vrací předpřipravená data.