První kroky do IT: Jak získat práci junior vývojáře

Při ladění se vyvarujte časté chyby – spoléhání na console.log v produkčním kódu. Nejenže to zahlcuje konzoli, ale může to také ovlivnit výkon aplikace. Místo toho používejte breakpointy a pokud potřebujete dočasné výpisy, vždy je po opravě odstraňte. Dále si zvykněte na to, že prohlížeče často rozdělují chyby do dvou kategorií: syntaktické (např. chybějící závorka) a běhové (např. volání nedefinované funkce). Syntaktické chyby se zobrazí hned při načtení skriptu, běhové až při spuštění dané části kódu. Vždy čtěte celý text chyby – obsahuje název souboru a číslo řádku, což je první stopa k nalezení problému.

Dalším bodem je délka zprávy. Krátké shrnutí je povinné, ale podrobný popis by měl být maximálně pár odstavců. Pokud potřebujete vysvětlit více, je lepší rozdělit změny na menší commity. Nepište ale ani zprávy, které jsou jen shrnutím diffu – to je zbytečné. Místo toho se zaměřte na kontext: jaké problémy změna řeší, jaké jsou její vedlejší účinky, co by mohlo být překvapivé. Tím pomůžete kolegům i budoucímu sobě.

Klíčové je rozlišovat mezi „co" a „proč". Diff vám ukáže, co se změnilo, ale ne proč. Proto v popisu vždy vysvětlete důvod. Například místo „Změněna barva tlačítka" napište „Změněna barva tlačítka na tmavší, aby byl lépe viditelný na světlém pozadí". Taková informace šetří čas při revizi kódu i při budoucí údržbě. Pokud je změna složitější, rozdělte ji do více commitů, ať každý dělá jednu věc. To usnadní reverz a hledání příčiny chyb.

Častou chybou je psát zprávy v minulém čase, jako byste popisovali hotovou věc. Lepší je použít rozkazovací způsob nebo přítomný čas, protože to odpovídá tomu, co commit dělá, když je aplikován. Například „Přidej testy pro přihlášení" je jasné a akční. Vyhněte se také vágním slovům jako „úpravy", „oprava" nebo „refaktoring" – pokud neřeknou, co konkrétně je upraveno, opraveno nebo refaktorováno. Vždy doplňte, co je předmětem změny, ať už jde o soubor, funkci nebo chování.

Na pohovor si připravte krátký příběh o projektu, který jste dělali. Vysvětlete, proč jste ho dělali, jaké problémy jste řešili a co jste se naučili. Nebojte se přiznat, co nevíte – u juniorů se to očekává. Ale ukážete, že přemýšlíte, pokud si předem nastudujete základní koncepty: algoritmy, datové struktury, HTTP, relační databáze. Nepodceňujte ani logické úlohy – na pohovorech bývají běžné.

Na závěr si zkuste přečíst svou zprávu očima někoho, kdo projekt nezná. Pokud by mu dávala smysl a věděl by, proč byla změna provedena, máte vyhráno. A pokud si nejste jistí, podívejte se na historii svých posledních commitů – často uvidíte, co je třeba zlepšit. Psaní kvalitních zpráv je dovednost, která se dá trénovat, a odměnou je vám přehledná historie, která šetří čas při každé spolupráci.

Při odhadu implementace si všímejte technických rizik, neznámých závislostí a nutnosti integrace s jinými systémy. Tato rizika zvyšují čas, takže je započítejte do odhadu. Často se stává, že vývojář odhadne kód na 3 dny, ale zapomene na testování, code review, opravu chyb a nasazení. Stanovte si pravidlo, že odhad implementace vždy obsahuje i testy a „buffer" na neočekávané komplikace – obvykle 20–30 % navíc.

Ladění JavaScriptu v prohlížeči je každodenní rutinou každého vývojáře. Přesto mnoho začátečníků stále spoléhá na vypisování hodnot do konzole přes console.log a při složitějších chybách tápou. Klíčem k rychlému řešení problémů je aktivní využití nástrojů, které prohlížeč nabízí přímo ve svém vývojářském rozhraní. Nemusíte instalovat nic navíc – stačí otevřít nástroje pro vývojáře, obvykle klávesovou zkratkou F12 nebo Ctrl+Shift+I.

Psaní smysluplných commit zpráv je dovednost, která se vyplácí především při zpětné dohledatelnosti změn. Když se kód po měsících vrátíte, nebo když ho prochází jiný člen týmu, kvalitní zpráva ušetří hodiny zmatků. Nejde o žádnou vědu – stačí dodržet pár zásad, které vám i ostatním usnadní orientaci v historii projektu.

Při navrhování pyramidy začněte analýzou rizik. Zaměřte se na kritické části systému, jako je zpracování plateb, přihlašování nebo výpočet cen. Pro ně napište jednotkové testy s robustními mocky. Ujistěte se, že testy netestují implementaci, ale chování. To znamená, že test by měl projít i po refaktoringu vnitřní struktury třídy, pokud se nemění vnější rozhraní. Typická chyba: test ověřuje, že byla zavolána metoda na mocku, místo aby kontroloval výsledek. Takový test je příliš svázaný s detaily a snadno se rozbije.