Stát se seniorem není jen o tom, kolik toho víš — je to taky o tom, jak pracuješ s kódem a s lidmi. Dvě stejně technicky schopné juniory odliší to, jestli umí čistě posílat změny, dávat a přijímat code review a sepsat, co a proč chtějí postavit. Tahle kapitola je o řemesle kolem samotného programování.
Pár pojmů na úvod
- Git = nástroj na verzování kódu (uchovává historii změn, umožňuje práci víc lidí najednou).
- Branch (větev) = oddělená linie práce, kde si vyvíjíš změnu, aniž bys rozbil hlavní kód.
- PR / MR (Pull/Merge Request) = návrh změny k zařazení, který si ostatní projdou (review).
- Code review = kontrola změny jiným člověkem před zařazením.
Git a jak posílat změny
Základní pracovní postup, který uvidíš skoro všude:
- Malé, logické commity s jasnou zprávou (co a proč), ne „fix" a „asdf". Historie má vyprávět příběh.
- Krátké větve, časté slučování. Čím déle větev žije stranou, tím bolestivější je pak ji zařadit (konflikty). Většina týmů jede GitHub flow (krátkožijící feature větev + PR), část jde až k trunk-based (slučovat rovnou do hlavní). Společné je: drž větve krátké, ať se daleko nerozejdou.
- Malé PR. Změnu o 50 řádcích ti někdo zreviduje pořádně; změnu o 2000 řádcích nikdo pořádně neprojde a jen „schválí".
Code review — proč a jak
Code review není buzerace — chytá chyby dřív, šíří znalosti v týmu a drží konzistentní kvalitu.
Když reviduješ:
- Soustřeď se na správnost, čitelnost a hraniční případy, ne na osobní vkus („já bych to napsal jinak" není důvod).
- Buď konkrétní a laskavý — komentuj kód, ne člověka. Ptej se („nešel by tu race condition?"), nementoruj.
Když dostáváš review:
- Ber to jako pomoc, ne útok. Cizí oči vidí, co ty ne.
- Malý PR = rychlejší a lepší review. Pomáháš tím i sobě.
Design dok / RFC — přemýšlej dřív, než stavíš
Než se pustíš do něčeho většího, sepiš krátký design dokument (často se mu říká RFC). Je to větší bratr ADR z Tech Choices: jaký problém řeším → jaké mám možnosti → co volím a proč → jaké to má důsledky a rizika.
Smysl: dostat zpětnou vazbu, dokud je změna ještě levná (na papíře), ne až po týdnu kódování. Navíc tě psaní donutí myšlenku promyslet — když ji neumíš vysvětlit, často ji ještě nemáš domyšlenou. A je to schopnost, kterou se senior pozná: umět návrh sepsat a obhájit.
Pár dalších návyků seniora
- Rozsekni velkou práci na malé kroky, které jdou nasadit samostatně (souvisí s feature flags — nasaď nehotové schované).
- Nech po sobě stopu — commit zprávy, PR popisy, ADR. Za rok (a kolegům) to ušetří hodiny.
- Automatizuj, co se opakuje — testy, lint, formátování běží v CI, ne v hlavě.
Failure modes — jak se to dělá špatně
- Obří PR → nikdo ho pořádně nezreviduje, jen „schválí" → bugy projdou.
- Dlouho žijící větev → bolestivé slučování a konflikty.
- Review zaměřené na vkus → hádky o styl místo o správnost (styl ať řeší automatický formátovač).
- Stavět velkou věc bez design doku → po týdnu zjistíš, že to mělo být úplně jinak.
- Nečitelná historie (
fix,asdf) → za půl roku nikdo nepozná, proč se co změnilo.
🛠️ Cvičení
- Rozsekni PR. Máš jednu velkou změnu (nová funkce + refaktor + oprava). Navrhni, jak ji rozdělit do menších PR a v jakém pořadí.
- Napiš commit zprávy. Pro tři smyšlené změny napiš dobrou commit zprávu (co a proč) a porovnej s „fix".
- Code review. Dostaneš PR, kde je
SELECT bez tenant_ida money ve floatu. Napiš dva laskavé, konkrétní review komentáře. - Design dok. Pro „přidáme do appky vyhledávání" napiš kostru design doku (problém → možnosti → rozhodnutí → rizika).
- Trunk-based vs dlouhé větve. Vysvětli na příkladu, proč týdny žijící větev bolí víc než časté slučování.
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- Rozsekni PR — rozděl na tři menší PR v pořadí refaktor → nová funkce → oprava (každý samostatně nasaditelný a zrevidovatelný); nehotové části schovej za feature flag. Pozor: malou změnu někdo zreviduje pořádně, obří PR jen „schválí" a bugy projdou.
- Napiš commit zprávy — každá zpráva řekne co a proč (např. „fix: zaokrouhli cenu na haléře nahoru, jinak faktury neseděly"), ne jen „fix" nebo „asdf". Pozor: historie má vyprávět příběh — za půl roku nikdo nepozná, proč se co změnilo, když tam je „fix".
- Code review — komentuj kód, ne člověka, konkrétně a laskavě, radši se ptej: u
SELECT bez tenant_id„nešlo by sem doplnittenant_id, ať nevidíme cizí data?", u money ve floatu „nepřešli bychom radši na celá čísla/decimal kvůli haléřům?". Pozor: drž se správnosti a hraničních případů, ne osobního vkusu (styl řeší formátovač). - Design dok — kostra: problém (chceme vyhledávání) → možnosti (SQL LIKE vs full-text vs externí engine) → rozhodnutí a proč → rizika a důsledky. Pozor: piš ho předem, dokud je změna levná (na papíře), ne až po týdnu kódování.
- Trunk-based vs dlouhé větve — týdny žijící větev se rozejde od hlavní a slučování bolí (kupí se konflikty); časté slučování malých kroků drží rozdíly malé a problémy odhalí hned. Pozor: nehotové části schovej za feature flag, ať můžeš slučovat brzy.
🧠 Otázky & odpovědi
Proč jsou malé PR lepší než velké?
Protože malou změnu (desítky řádků) ti někdo zreviduje pořádně — projde logiku, hraniční případy, chyby. Velkou změnu (tisíce řádků) nikdo poctivě neprojde a jen ji „schválí", takže bugy projdou. Malé PR se navíc rychleji slučují (míň konfliktů) a snáz se vrací zpět, když je problém. Rozsekat práci na malé kroky je dovednost sama o sobě.
K čemu je code review a na co se při něm soustředit?
Code review chytá chyby dřív, šíří znalosti v týmu a drží kvalitu konzistentní. Soustřeď se na správnost, čitelnost a hraniční případy, ne na osobní vkus (styl ať řeší automatický formátovač). Komentuj kód, ne člověka, buď konkrétní a laskavý a radši se ptej, než mentoruj. Když review dostáváš, ber ho jako pomoc — cizí oči vidí, co ty ne.
K čemu je design dok / RFC a kdy ho psát?
Píšeš ho před stavbou něčeho většího: jaký problém řeším → jaké mám možnosti → co volím a proč → rizika. Smysl je dostat zpětnou vazbu, dokud je změna levná (na papíře), ne až po týdnu kódování. Navíc tě psaní donutí myšlenku promyslet. Je to větší bratr ADR a schopnost „návrh sepsat a obhájit" patří k tomu, čím se pozná senior.
Proč krátké větve a časté slučování (trunk-based)?
Protože čím déle žije větev stranou od hlavní, tím víc se obě rozejdou a tím bolestivější (a rizikovější) je pak změnu zařadit — kupí se konflikty. Časté slučování malých kroků do hlavní větve udržuje rozdíly malé a problémy se objeví hned, ne až po týdnech. Nehotové části se schovají za feature flag.
Proč záleží na dobrých commit zprávách a historii?
Protože kód se čte mnohem víc, než píše — a za půl roku (nebo kolegovi) historie odpovídá na otázku „proč se tohle změnilo". Zpráva „fix" nebo „asdf" neřekne nic; dobrá zpráva (co a proč) ušetří hodiny pátrání a pomůže pochopit rozhodnutí, aniž by se musela překopávat naslepo. Je to levná investice s velkou návratností.