Základní pravidlo je jednoduché: commit zpráva má popisovat změnu, ne opsat diff. Pokud napíšete „oprava bugu", neřeknete nic. Pokud napíšete „oprava null pointeru při parsování prázdného JSONu v ReportService", řeknete přesně to, co potřebujete. Nikdo nechce číst commit „fix" ani „update". Takové zprávy jsou k ničemu, protože nedávají kontext. A kontext je to, co dělá historii použitelnou.<br>
<br>
<br>
<br>
První rok v IT je o růstu, ale taky o tom, že se naučíš říkat si o pomoc. Pokud se ti něco zdá přehnané, jako třeba termíny nebo rozsah úkolů, řekni to včas, ne až na poslední chvíli. Nikdo nečeká, že budeš hned perfektní. Důležité je, že se zlepšuješ a že jsi schopen přinést hotovou práci. Za pár měsíců zjistíš, že věci, které tě na začátku stresovaly, jsou rutina. A to je přesně ten moment, kdy se můžeš posunout na další úroveň.<br>
<br>
<br>
<br>
Psát commit zprávy je rutina, kterou většina vývojářů odbývá. Přitom právě ony rozhodují o tom, jak rychle se v historii projektu zorientujete vy i vaši kolegové. Špatně napsaná zpráva typu „oprava" nebo „update" je k ničemu, když se za tři měsíce snažíte zjistit, proč se změnilo chování nějaké funkce. Smysluplná commit zpráva není formalita, ale nástroj, který šetří hodiny hledání v logu.<br>
<br>
<br>
<br>
Nejčastější chyby, které dělají historii nepřehlednou Mezi typické prohřešky patří vágní slovesa jako „oprava", „úprava", „vylepšení" bez bližšího určení. Další častý problém je míchání nesouvisejících změn do jednoho commitu – když v jednom commitu opravíte chybu, přidáte novou funkci a přejmenujete proměnnou, je to noční můra. Každá logická změna by měla být ve vlastním commitu, aby se dala v případě potřeby revertovat bez vedlejších škod. A pozor na hlášky typu „hotovo", „snad to funguje" nebo „nechápu, proč to nešlo". Tyto zprávy říkají o změně úplně všechno, jen ne to podstatné.<br>
<br>
<br>
<br>
Druhý problém je vynechání kontextu. Commit „změna konfigurace" může znamenat cokoliv – změnu portu, přidání proměnné prostředí, úpravu timeoutu. Vždy uveďte, co konkrétně a proč. Třeba „zvýšení timeoutu na 30 s kvůli pomalé odpovědi externí API". Tím dáváte budoucímu čtenáři šanci rozhodnout, jestli je změna relevantní pro jeho problém, aniž by musel prolézat celý diff. A pokud používáte ticketovací systém, zmínka o čísle úkolu je užitečná – ale ne místo popisu, nýbrž jako doplněk.<br>
<br>
<br>
<br>
Při psaní životopisu neuvádějte to, co neumíte, ale to, co jste se naučili a jak jste to použili. Popište svůj testovací projekt, uveďte konkrétní příklad chyby, kterou jste našli, a jak jste ji popsali. Vysvětlete, jak jste postupovali při návrhu testů. Nezmiňujte, že nemáte praxi; místo toho zdůrazněte svůj systematický přístup a schopnost samostatné práce. Vyhněte se tvrzením typu „jsem rychlý učeň" – to je prázdná fráze. Konkrétní činy jsou vždy přesvědčivější.<br>
<br>
<br>
<br>
Pokud máte více feature větví, které spolu souvisí, zvažte, zda je neřešit na jedné větvi, ale postupně. Často se stává, že dvě větve mění stejný soubor a po mergu druhé z nich vzniknou zbytečné konflikty. Místo toho si práci naplánujte tak, aby se větve vzájemně nepřekrývaly, nebo je slučte do jedné „epické" větve, kterou pak mergnete najednou. Tím se vyhnete situaci, kdy máte pět větví čekajících na merge a každá obsahuje změny, které závisí na jiné.<br>
<br>
<br>
<br>
Když píšete JavaScript, snadno podlehnete dojmu, že rychlé řešení je to nejlepší. Ale za tři týdny se k vlastnímu kódu vrátíte a zjistíte, že nerozumíte ani vlastním proměnným. Čistý kód není o estetice, ale o tom, abyste dokázali rychle najít chybu a bezpečně přidat novou funkci. Základní pravidlo zní: pište kód pro lidi, ne pro stroj. Stroj přečte cokoli, ale člověk potřebuje jasné pojmenování, krátké funkce a minimální překvapení.<br>
<br>
<br>
<br>
Co rozhoduje u prvního pohovoru a jak se na něj připravit Před pohovorem si projdi vlastní projekty, i ty malé z kurzu nebo z vlastního učení. Připrav si krátké povídání o tom, co jsi dělal, proč jsi zvolil zrovna tohle řešení a co bys příště udělal jinak. Pokud projekt nemáš, vytvoř si jednoduchou aplikaci, která řeší reálný problém, třeba správu úkolů nebo evidenci výdajů. Nezapomeň, že kvalita kódu je víc než počet technologií. Tři funkční projekty, kterým rozumíš do hloubky, udělají lepší dojem než deset rozpracovaných tutoriálů.<br>
<br>
<br>
<br>
Proč je pojmenování polovina úspěchu Největší problém většiny JavaScriptových projektů jsou proměnné jako data, x nebo temp. Takový název nic neříká a nutí vás procházet celou funkci, abyste zjistili, co obsahuje. Pojmenovávejte proměnné podle toho, co představují, ne podle toho, jak vznikly. Například místo let a = getUsers() použijte let users = getUsers() a místo let flag = true zvolte let isAdmin = true. Boolean hodnoty začněte předponou is, has nebo can – hned je jasné, že jde o pravdivostní výraz.
