Pracovní den programátora

Jak vypadá pracovní den programátora? To je otázka, kterou jsme já i další měli na střední škole, a měli jsme problémy si ji zodpovědět. Moje představa byla, že sedím v místnosti, sám a před počítám, a píšu řádek za řádkem kódu do Visual Studia, z něhož nakonec vyjde hotový program.

Ale to mi nestačilo. Jistě, programátor v práci píše kód, ale jak to přesně vypadá? Co vlastně dělá? Pracuje sám nebo s dalšími? Jak ví, co má programovat? 

Tyto otázky se pokusím zodpovědět v tomto článku. Moje informace pochází z mých vlastních zkušeností při programování v pozici zaměstnance, a také ze zkušeností mých kamarádů, kolegů a známých. 

Samozřejmě je pravda, že každá firma je trochu jiná; dokonce i každý den je trochu jiný, a také každý programátor. V tomto článku popisuji, co myslím, že je nejčastější, ale vůbec bych se nedivil, kdyby pro někoho jiného pracovní den vypadal docela jinak.

Skladba dne. Pracuješ většinou osm hodin denně, z nichž zhruba:

  • hodinu věnuješ komunikaci v týmu;
  • hodinu vyjasňování požadavků;
  • hodinu náhodným věcem okolo; a
  • zbývajících pět hodin čtení a psaní kódu.

Psaní kódu tak zůstává jednou z nejdůležitější věcí, co děláš (bez toho, koneckonců, nebude program), ale oproti práci na vlastním hobby projektu se přidává mnoho dalších aktivit.

Komunikace v týmu. Největší rozdíl oproti mé představě programování je, nakolik moc je komunikace součástí práce. Pracuješ v týmu 2 až 10 programátorů tak, že společně vyvíjíte stejný produkt: všichni spolupracujete na stejném zdrojovém kódu, často pro jedinou aplikaci (např. “Malování”) nebo, pokud je program příliš velký, dokonce na části aplikace (např. “kontrola anglické gramatiky v Google dokumentech”).

S kolegy mluvíš o plánech na další vývoj, žádáš je o pomoc a pomoc poskytuješ, domlouváte se na detailech úkolů a řešíte společné problémy. Často se stane, že potřebuješ pracovat na části kódu, které tvůj kolega rozumí víc než ty. V takovém případě za ním přijdeš, a věc proberete spolu. 

Nově napsaný kód prochází code review: až ho napíšeš, tak většinou přijde další programátor, podívá se na něj, pokusí se zjistit, jestli je celý v pořádku, popř. jestli jsi v něm na něco nezapomněl, a pak se společně domluvíte na tom, jestli ještě kód trochu nepoupravit. Kód tak nikdy není jen “tvůj”, pracujete na něm spolu.

Ve všech týmech se také konají různé schůzky (“meetingy”), při kterých se část týmu nebo celý tým sejde v jedné místnosti (do roku 2019; od roku 2020 se kvůli covidu-19 jedná o videohovory nebo audiohovory) a mluví o nějakém tématu. Vtipkuje se, že jak postupuješ v kariéře na vyšší pozice, tak píšeš stále méně kódu a účastníš se stále více meetingů.

Ve větších společnostech také často komunikuješ s lidmi mimo svůj tým, protože vaše práce nějak souvisí s prací někoho jiného. Pro takovou komunikaci se používá e-mail nebo nějaký instant messenger, např. Microsoft Teams.

Vyjasňování požadavků. V pozici zaměstnance-programátora bude většinou zadávat cíle někdo jiný než ty sám. Tyto cíle ale často nebudou úplně přesné. Může se k tobě například dostat zadání “udělej, aby se rozdělaný obrázek automaticky ukládal každých pět minut,” ale ty ještě budeš muset domyslet např. kam se má ukládat, co se má stát, pokud uživatel ještě obrázek ani nepojmenoval, nebo co zobrazit, pokud automatické uložení z nějakého důvodu selže. Ve větších týmech nebo společnostech bývá často výsledek vyjasňování ve formě textu v angličtině, od kterého se pak můžeš odrazit při samotném programování. 

Čtení kódu. Projekty, na kterých budeš dělat, jsou většinou spíše větší než menší, a nedokážeš je do hlavy pojmout celé. Proto většinu času strávíš čtením zdrojového kódu: buď toho, co napsali jiní, nebo i svého vlastního, jehož strukturu už jsi mezitím zapomněl. Během čtení kódu se snažíš si v hlavě vytvořit mentální obraz situace a ujasnit si, kde musíš udělat změnu. 

Psaní kódu. Podstatnou část práce pak samozřejmě věnuješ samotnému psaní nového zdrojového kódu. Část kódu, který budeš psát, budou opravy chyb (“bugů”). Je mnoho technik, jak hledat a nacházet chyby a opravovat je, a budeš nejspíš použít všechny. Občas tak, že budeš přídávat do kódu ladící příkazy, občas budeš pročítat logy, občas budeš program procházet krok po kroku s debuggerem, a občas budeš prostě jen spouštět program znovu a znovu.

Velká část tvé práce bude nejspíše také programování nových funkcí, při kterém budeš nejen psát samotný kód, ale i vymýšlet, co vlastně má funkce přesně dělat, navrhovat, které její kusy dát do jaké části kódu, nebo vymýšlet, jakým způsobem lze funkci naimplementovat nejefektivněji.

U mnoha projektů jsou také důležité testy, obzvláště automatické jednotkové testy (“unit testy”). Není nezvyklé, že strávíš psaním testů více času než psaním samotného funkčního kódu, obzvláště pokud pracuješ na větší aplikaci, u které je její stabilita důležitější.

Bug tracking. Když pracuješ na větším projektu, úkoly jsou rozdělené na podúkoly a pak ještě více na podúkoly. Nikdo by nevěděl, jak splnit úkol typu “Naprogramuj obrázkový editor,” tedy se úkol rozdělí na podúkoly typu “přidej funkci na proměnu obrázku na černobílý obrázek” nebo “přidej export do formátu BMP” nebo “oprav tu chybu, že editor spadne, když vybereš bílou barvu”. Tyto úkoly si tým udržuje v databázi, které se říká “bug tracking system”.

Když se pak člověk v týmu rozhoduje, na jakém úkolu by měl nyní pracovat, může to často udělat tak, že se podívá do této databáze, vybere si nějaký z těchto úkolů a začne na něm pracovat (např. vyjasněním požadavků). Úkoly ze systému také může přiřazovat nadřazený kolega nebo je může tým vybírat společně na plánovací schůzce.

Správa verzí. Zdrojový kód, na kterém váš tým pracuje, bývá uložen v “systému správy verzí”, databázi, která si pamatuje všechny verze zdrojového kódu tak, že nemůžeš omylem smazat důležitý kód (resp. pokud ho smažeš, je snadné ho obnovit). Tento systém je také zodpovědný za automatické skládání změn od více programátorů dohromady. Tedy pokud ty přidáš jednu funkci a zároveň tvůj kolega přidá druhou funkci, ve výsledku bude mít zdrojový kód obě funkce.

Plánování. Část času také věnuješ sestavování architektury systému a dlouhodobému plánování. To je třeba obzvláště u náročnějších úkolů, které můžou zabrat třeba několik měsíců. Toto se dá dělat nad papírem a tužkou, ale často potřebuješ si i hledat informace na internetu a v kódu nebo komunikovat s kolegy.

Ostatní. Kromě toho se vždy naskytne hromada dalších věcí, které ale dohromady nezaberou tolik času. Například vyplňování formulářů, schůzky ohledně hodnocení výkonů, povídání si o počítačových hrách, zábavné aktivity pro stmelování týmu, učení se nových programovacích technik nebo jazyků, a další.

 

Závěrem. Programování z pozice zaměstnance mi stále přijde jako nejlepší povolání, které jsem si mohl vybrat. Je ještě zábavnější, rozmanitější a zajímavější, než jsem si to na střední škole představoval. Téměř vše, co jako programátor dělám, mě baví a za jinou kariéru bych neměnil.

Pokud vás programování zaujalo, tak mohu doporučit programování i jako povolání.

  1. Pavel Halbich napsal:

    Ahoj, v příspěvku mi chybí pár důležitých věcí:

    1) Většina větších týmů / týmů v rámci většího produktu jede agilně (aby mohli pružně reagovat na aktuální stav dodávaného systému a zpětnou vazbu od zákazníků či stakeholderů). To v praxi znamená obvykle dvoutýdenní vývojový cyklus – sprint (kdy tým dodá nějakou konkrétní funkci, něco opraví atd.) a pak má vývojář pravidelně meetingy:
    – Backlog refinement – procházení tiketů z nějakého trackovacího systému (třeba Jira, Trello apod.), jejich naceňování (odhad náročnosti). Obvykle je před retrem a planningem (níže)
    – Retrospektiva – tým si řekne co se povedlo a co ne, může zde reagovat a adresovat různé problémy („od čtvrtka je kolega příliš náladový a přenáší se to do celého týmu, děje se něco?“). Tento meeting je zhodnocení konce sprintu. V našem týmu tomu interně s humorem říkáme „hejtovací středa“.
    – Plánování – obvykle následuje ihned po retru a smyslem je podívat se na objem dodávané práce za poslední dobu a na základě toho a aktuálních kapacit na další sprint (lidi mimo dovolené atd.) smysluplně naplánovat vývoj na další dva týdny. Do toho se promítá hrozně moc faktorů – aktuální potřeby bussinessu, reakce na zhoršující se metriky („zhoršila se nám konverze nakupujících a snížily se objednávky – měli bychom tento problém řešit a fixnout známé chyby v nákupním procesu“), potřeba přípravy na další sprinty, dodání práce pro závislé týmy (implementace funkcionalit API, pokud firma jede microservice architecture), …
    – každý den (ráno) bývá standup či daily – na něm si tým během 5-15 minut řekne, na čem kdo dělal, co bude dělat, jestli je někdo něčím blokován, jestli potřebuje pomoct atd. Ideální meeting pro pravidelnou kontrolu postupu práce k cíli sprintu.

    2) Nemyslím si, že psaní kódu je to nejdůležitější. Nejdůležitější je IMHO přemýšlení nad strukturou projektu, řešení architektury a logiky kódu. Pokud neděláš tohle, tak pak začneš něco psát, pak zjistíš, že to třeba nejde, nebo musíš udělat strašné ohacky, aby to šlo a celkově tak trochu prasíš kód. Kdežto když máš dobře rozmyšlené co, kde a proč chceš něco dělat a zapadá to do používané / cílené architektury programu, tak samotná implementace už je pak spíše cvičení pro chytřejší opici. Ne nadarmo jsou seniorštější vývojáři ti, co „napíší hlavičky funkcí“ a kodér junior jen pak doplní tělo na základě požadovaného vstupu a výstupu.

    3) Poměr vývoje nové funkcionality a fixování současné velmi záleží na projektu. Pokud vyvíjíš nový systém „na zelené louce“, tak budeš spíše dodávat funkcionalitu. Pokud se dostaneš do projektu, který je dlouho běžící a nebo je to rovnou údržba nějakého historického kódu (a nikdo nechce dát prachy na to to přepsat do něčeho novějšího a udržitelnějšího / funguje to, tak na to nebudeme hrabat), tak strávíš mnohem více až většinu času hledám a fixováním bugů. Většina z nich je buď triviální opomenutí a nebo důsledek chybějícího rozmyšlení z bodu 2.

Napsat komentář