Nedávno jsem od jednoho čtenáře blogu dostal dotaz. Se svolením autora budu citovat: „Jak vypadá konkrétní práce programátora? Nemám totiž vůbec ponětí. Dostaneš nějaké zadání a určený čas k vyřešení? Nebo se sejde parta programátorů, rozeberou si úkoly a pracují ve skupinkách? Můžeš mi popsat nějakou konkrétní práci, kterou jsi někde dostal?“

Tento dotaz mi přijde opravdu zajímavý, hlavně proto, že jsem si podobné otázky kladl před tím, než jsem nastoupil do své první práce. Mou odpověď bohužel negativně ovlivní několik faktorů. Za prvé jsem nyní teprve v druhém zaměstnání, tudíž nemám moc praktických zkušeností jak to chodí jinde. Díky tomu bude moje odpověď dost ovlivněna tím, co jsem zažil, nebo co jsem se doslechl od známých. Druhý faktor je ten, že o předchozím zaměstnání toho nemůžu moc říct. Budu se ale snažit odpovědět alespoň abstraktně, takže snad nějaké poznatky pomůžou. Tak tedy hurá na to, v následujících řádcích se dočtete co to ti programátoři vlastně dělají.

Jak to probíhá

Hned ze začátku musím bohužel zklamat. Neexistuje totiž žádný univerzální postup práce pro programátory. Pro většinu lidí mimo tým to vypadá jako jeden obrovský chaos. Bohužel to mnohdy vidí stejně i členové týmu. Obecně se dá říct, že se jedná o neustálý boj mezi managementem (ti chtějí mít vše hotovo co nejdříve) a programátory (snaží se přesvědčit management, že termíny jsou nereálné). Obvykle to končí takovým kompromisem, kdy obě strany nadávají, ale ve výsledku to funguje :)

Aby se ten chaos nějak zvládl, existují různé metodiky vývoje softwaru. Nebudu je tedy jmenovat, případným zájemcům pomůže Google. Já měl zatím zkušenosti pouze se Scrumem (který jsme ale tak úplně nedodržovali, takže to nebylo ono). Třeba u toho scrumu to bylo tak, že vývoj byl rozdělen na nějaké kratší časové úseky (tuším že měsíce) a na konci jednoho období se naplánovaly úkoly na další období. Pokud se jednalo o nějaký důležitý úkol, byl uveden i nějaký termín (v řeči programátorů deadline…což je mimochodem velmi trefný název ;) ). U ostatních úkolů každý programátor udělal časový odhad (estimate). Tady narážím na důležitou věc…odhadování časové náročnosti úkolu.

Estimate – náhodně vygenerované číslo?

Odhad je od slova odhadovat, tudíž je každému jasné, že odhad se nebude s realitou shodovat naprosto přesně. Ideálně by ale měl být co nejpřesnější. Z mých zkušeností je přesnost odhadů dána hlavně dvěma faktory:

  1. zkušenosti programátora: čím má programátor více zkušeností, tím dokáže lépe odhadnout, co se za daným problémem může skrývat a jaké můžou vzniknout komplikace.
  2. znalosti systému (aplikace) se kterou pracuje: pokud někdo pracuje s kódem, ve kterém se moc nevyzná, nejsou odhady moc přesné. Takový člověk nevidí do kódu tak dobře, aby chápal jaké změny bude třeba provést a jaké problémy se zaváděním změn můžou nastat.

Takže odhady od junior programátorů, kteří jsou na projektu noví jsou asi tak přesné, jako náhodně vygenerované číslo :)

Je to různé, ale…

Nejde tedy říct, že vývoj probíhá tak a tak. Dalo by se říct že co firma (nebo dokonce tým), to jiný pracovní postup. Pokud ale člověk nastupuje jako junior programátor, může se setkat s určitými “jistotami”.

Časté jsou obavy, že vás zavalí hned první den práci a vy si s tím nebudete vědět rady. Toho jsem se taky bál…a to pořádně. Když jsem tehdy nastupoval do zaměstnání na pozici C++ programátor, tak jediné mé znalosti s C++ byly ty, které jsem se dočetl v knize Mistrovství v C++. Aby toho nebylo málo, tak tu knihu jsem dočetl asi jen do poloviny ;) Mé znalosti jazyka a taky programování obecně byly minimální. Když jsem ale nastoupil, byl jsem mile překvapen. Prvních několik dní se člověk stejně jen rozkoukává a hlavně má k dispozici nějakého zkušenějšího vývojáře. Takže první týdny v práci jsou studijní. Učíte se o firemních procesech, o náplni práce a začnou vás seznamovat s kódem, na kterém budete pracovat.

Když to tak vezmu, tak za první měsíc v první práci jsem se naučil o programování více, než za celý svůj život. Kam se na to hrabe škola. První úkoly jsou většinou jednoduché a hlavně je vám vždy nějaký ten senior k dispozici. Až budete hotovi, váš kód by měl projít přes nějakého seniora (code review), aby se ověřilo, že je vše správně. No a než se nadějete, uvědomíte si, že řešíte stejně složité úkoly jako ostatní a pomalu už zaučujete někoho dalšího :)

U velkých softwarových firem se můžete většinou setkat se zavedenými firemními procesy, které stačí dodržovat. Některým lidem to může vyhovovat, ale mi osobně to moc nesedlo. V mé druhé práci je to třeba zase jinak. V týmu jsem zatím jediný vývojář a projekt se teprve rozjíždí. Nevýhoda je, že vedle nesedí žádný ten senior vývojář, ale na druhou stranu má člověk více volnosti a může využít svou kreativitu. Žádné zavedené procesy tu nejsou, takže člověk může ovlivnit více věcí, než jen kód který napíše.

Dvě práce a dva naprosto odlišné pracovní postupy. Pokud se budete někam hlásit, zkuste se tedy poptat lidí, co ve firmě pracují. To je asi nejlepší zdroj informací :)

Základ všeho je tým

Jedna z nejdůležitějších věcí, které programátor musí zvládat je dobrá komunikace a práce s týmem. Můžete být skvělý programátor, můžete být ve firmě nejlepší, ale pokud nebudete efektivně komunikovat s ostatními a nebudete umět spolupracovat, nedopadnete moc dobře. Dobrou komunikaci s týmem (i s ostatními týmy) vidím jako naprostou nutnost. Když budete kopat sami za sebe, bude vše trvat déle. Hodně problémů už bylo vyřešeno v minulosti někým jiným. Tým by měl být sehraný a jeho členové by měli neustále spolupracovat a navzájem si vypomáhat. Úkoly řeší nejčastěji programátor sám, setkal jsem se ale i s úkoly, na kterých pracovalo několik lidí najednou. Je to případ od případu, opět se nedá generalizovat.

Umění nebo dělnická činnost?

Podle mě je programování obojí. Někdy programátor má jasné zadání co má provést (většinou od nějakého architekta) a pak už jen kódujete (prostě dělničina…vemete lopatu a kopete dokud tu jámu nevykopete). Pak jsou případy, kdy není zadání nijak přesně vymezené. Tam musíte přemýšlet, jak danou věc provedete. A nebo taky u hledání a opravy chyb. To je další případ, kdy se nejedná o dělnickou práci, ale o umění a mentálně náročnou činnost.

Když tedy uvidíte programátora se sluchátky na uších a s nohama na stole, nemusí to znamenat že se fláka. Osobně jsem nejvíce chyb vyřešil během relaxace. U programování (pokud nejde o výše zmíněnou dělničinu) není vztah mezi časem stráveným v kódu a množstvím provedené práce přímo úměrný. Ze začátku jsem s tím měl problémy a když jsem nečuměl do toho monitoru, tak jsem měl docela obavy, že to bude vypadat, jako bych se flákal. Naštěstí jsem tuhle počáteční fázi překonal a nyní když to potřebuju, tak si v klidu odpočinu. U mě to znamená pustit si hudbu (tak abych neslyšel okolí), zavřít oči, pohodlně se usadit a začít přemýšlet.

Jelikož se člověk nedokáže soustředit moc dlouho, považuju za samozřejmost dělat si pravidelné pauzy při práci. Zkoušel jsem několikrát pracovat v kuse těch 8 hodin (a více), ale prostě to není ono. Soustředěnost, efektivita, výkon a hlavně kvalita odvedené práce jde prudce dolů. Proto když už si všimnu že ztrácím pozornost, tak navštívím svou RSS čtečku, která mě neustále zásobuje něčím zajímavým ke čtení :) Taky pomůže nějaká procházka nebo pokec s kolegy. Kdyby mě někdo nutil pracovat celý den v kuse tak to odmítnu a odejdu, věděl bych totiž, že v takových podmínkách nemůžu zaručit nic kvalitního. Samozřejmě když se blíží deadline, tak je třeba ty pauzy minimalizovat ;)

Co dál?

Myslím si, že vše podstatné jsem již napsal. Pokud vás čeká vaše první zaměstnání na pozici programátora, tak doporučuju se tím nijak nestresovat. Není třeba žádných extra znalostí a zkušeností, jediné co by vám nemělo chybět je touha učit se. Však oni si vás tam ve firmě už nějak zaškolí, vycvičí a budete mít po problémech. Tenhle článek je tedy docela chaotický, spíše to berte jako takový souhrn postřehů :)

Na závěr, abych zodpověděl celou otázku, tak doplním ilustrační příklad práce, kterou jsem dělal:

Podle bug reportu při zobrazení dialogu s barvami problikne titulek dialogu. Tato chyba měla časový odhad týden. Začal jsem se tedy snažit chybu zreprodukovat, abych zjistil, jestli ji vůbec dokážu napodobit a pokud ano, zjistit další informace. Ve které verzi k chybě dochází a za jakých podmínek. Chyba se mi povedla napodobit v určité verzi aplikace. Začal jsem to tedy vyšetřovat a zjišťovat od jiného týmu, jestli se s něčím podobným nesetkali. Dostal jsem nějaké rady a tipy na to, kam se podívat a co to může způsobovat. Po vyzkoušení několika drobných úprav se ukázalo, že problém je složitější. Změnil jsem tedy časový odhad na dvojnásobek a několik dní jsem strávil debugováním. Po několika dnech se mi podařilo zjistit, že chybu nezpůsobuje komponenta, kterou jsem měl na starosti, ale systémová knihovna, kterou ta komponenta volá. Zjistil jsem tedy jak problém opravit, napsal jsem bugreport pro tu systémovou knihovnu, úkol jsem pozastavil a začal jsem řešit jiný. Až byl bug v systémové knihovně opraven, otestoval jsem, jestli chyba opravdu zmizela a daný úkol jsem uzavřel.

Je to jen jeden příklad z mnoha, ale pokud někdo má zájem o konkrétní příklad, tak myslím že mu tento bude stačit.

Pokud zůstaly nějaké otázky nezodpovězeny, klidně napište pod článek komentář a zeptejte se ;)

EDIT: v 4. díle 3. řady seriálu The Big Bang Theory je luxusní scénka, která ukazuje jak nejen vědci, ale i programátoři pracují :)

Další články zde na webu: