Začátek roku bývá tradičně spjat s volbou rozličných předsevzetí do nového roku. Jak dělat věci lépe a ku prospěchu vlastnímu i cizích. Dovoluji si tímto navrhnout seznam několika předsevzetí pro nadřízené všech programátorů a vývojářů. Zejména pak těch "interních", protože právě tam jsou podle mých zkušeností podmínky nejhorší. Tento seznam vznikl na základě mých dlouholetých osobních zkušeností lektora a konzultanta – a vrby, která často poslouchá stesky mnoha různých programátorů z různých společností. Vzhledem k tomu, že na splnění níže uvedených předsevzetí nemám osobní zájem (moje šéfová moc dobře ví, co programátor potřebuje), doufám že tento článek poslouží i jako jistá forma obrany oprávěných zájmů lidu programátorského.

Předsevzetí první: Dám vývojářům klid na práci

Vývoj software je – zejména ve fázi psaní kódu – jakýsi intelektuální ekvivalent žonglování. Žonglér se snaží udržet ve vzduchu hejno kuželek a programátor se zase snaží udržet si v paměti hromadu "dočasných proměnných". Musí si zapamatovat informace kde se právě v logice programu nachází, jaké tam jsou proměnné, jaké mají typy, předpokládané hodnoty a co se tam vlastně děje. To je činnost, která vyžaduje poměrně hluboké soustředění. Pokud není k dispozici, narůstá pravděpodobnost hloupých chyb,  které se většinou špatně hledají a odstraňují. Hloupé je, že pokud je koncentrace narušena, trvá relativně dlouho, než se programátor dostane do původního stavu – i krátké vyrušení tak třeba znamená ztrátu čtvrthodiny.

Pokuste se, aby programátoři měli k dispozici klidné pracovní prostředí. Velké openspace kanceláře jsou vhodné pro profese, kdy spolu lidé hodně komunikují, nebo pokud vykonávají nějaké rutinní práce. Programování je činnost vesměs individualistická a tomu by mělo odpovídat i pracovní prostředí. Klid na práci znamená méně chyb a rychlejší vývoj.

Předsevzetí druhé: Poskytnu vývojářům kvalitní pracovní nástroje

Kvalitními nástroji se rozumí jak hardwarové, tak softwarové vybavení. Vývoj software je kupodivu dost náročné na výpočetní prostředky. Nejde ani tak o samotné psaní kódu, ale o související operace – prohledávání, kompilaci a podobně. Standardem pro vývojářský stroj současnosti by měl být dostatek operační paměti (nejméně 4 GB, lépe 8) a zejména použití SSD – rychlých disků bez pohyblivých součástí. Tyto disky jsou stále ještě dražší než běžné rotační, ale jsou mnohonásobně rychlejší. A právě rychlost přístupu k datům je pro práci vývojáře podstatná, protože se to děje velmi často. Prostým upgradem disku lze zrychlit velkou část operací, typicky kompilaci – což je něco, co při vývoji programátor udělá za den v několika stovkách případů.

Je dobré poskytnout kvalitní a velké monitory – klidně dva nebo tři. Programátor potřebuje pro orientaci vidět co možná nejvíce textu (zdrojového kódu) najednou. Velký monitor nebo několik mu umožní aby se nemusel neustále  přepínat mezi okny a zapomněl, co vlastně chtěl udělat. Osobně pokládám za optimum (pro webový vývoj) tři monitory: jeden na kód, jeden na nástroje Visual Studia a jeden na web, který právě vyvíjím, případně dokumentaci a podobně. Hardware je – v porovnání s časem vývojáře – docela levný a dokáže udělat velký rozdíl.

Totéž se týká nástrojů softwarových – používejte aktuální verze a nebraňte se specializovaným doplňkům, které mohou produktivitu práce vývojářů zvýšit. Řada z nich nedá dopustit na nástroje jako je CodeRush nebo Resharper, jejichž cena je relativně nízká (v jednotkách tisíc korun) a mohou znamenat vyšší produktivitu a méně chyb.

Předsevzetí třetí: Budu podporovat používání hotových komponent

Samotný .NET Framework nelze brát jako konečnou, uzavřenou sadu, se kterou by si měl programátor bez dalšího vystačit. Teoreticky je to možné, v praxi to většinou nemá smysl. Pro řadu běžných i speciálních úkolů se vyplatí koupit hotové softwarové komponenty, než si to celé psát sami. To je jedna z nejčastějších stížností, se kterými se na kurzech setkávám: místo aby se koupila hotová komponenta, čtvrt roku totéž vyvíjíme sami.

Programátor stojí na veškerých nákladech firmu nejméně sto tisíc měsíčně. Balík kvalitních komponent pro tvorbu uživatelského rozhraní (od firem jako Telerik, Infragistics, DevExpress a další) stojí okolo tisíce dolarů včetně ročních upgradů a podpory, tedy zhruba stejně jako týden jeho práce. A stejně dobré komponenty za týden nenaprogramuje. Mnohdy ani za rok ne, protože to chce trochu jinou sadu dovedností a znalostí, než pro běžný vývoj a také zkušenosti, které tyhle firmy – pohybující se v oblasti léta – mají a vy ne. V řadě firem je nepřekonatelný administrativní problém něco takového koupit. Překonávejte tyto problémy, stojí to za to.

Předsevzetí čtvrté: Nebudu zbytečně omezovat vývojářům přístup k Internetu

Dost často se setkávám s tím, že programátoři mají v pracovní době omezený přístup k Internetu. Což rozhodně není dobrý nápad, protože drtivá většina relevantní informací je dnes publikována na blozích a v podobných online zdrojích. Třeba v případě .NET platformu se často i oficiální informace, rady a tipy objevují nejdříve na blozích jednotlivých lidí nebo vývojových týmů a až teprve mnohem později (pokud vůbec) se dostanou do MSDN a podobných zdrojů. Programátorská fóra, e-mailové konference, blogy, pro někoho třeba i Twitter jsou nedocenitelným zdrojem technických informací.

Setkal jsem se i s případem, kdy vývojáři měli přístup k Internetu sice neblokovaný, ale omezený datovým objemem 100 MB na den. Uvážíme-li velikost SDK, příkladů a třeba video záznamů (řada informací je dostupná třeba jenom jako záznamy přednášek z akcí, jako je MIX, TechEd a podobně), je to vyloženě směšné.

Předsevzetí páté: Umožním vývojářům smysluplné vzdělávání

Neříkám, že všechny vývojáře musíte ihned a okamžitě poslat na moje kurzy do Gopasu (ačkoliv bránit vám v tom samozřejmě nebudu :), ale dejte jim trochu času a prostoru na sebevzdělávání. Jak konkrétně to bude probíhat, to záleží hodně na osobních preferencích konkrétního vývojáře. Někomu vyhovuje školení, ale třeba já osobně bych z něj nic neměl. Abych něco pochopil, musím si to přečíst – typicky právě na nějakém blogu, viz výše. Někomu vyhovuje čtení, někomu kurzy, někomu konference.

Rád bych zdůraznil slovo "smysluplné". Setkal jsem se s případem, kdy firma vyslala programátora, ktedý nikdy předtím ASP.NET neviděl, v bezprostředním sledu na kurzy o ASP.NET pro začátečníky, pokročilé a specialisty. Nejspíš předpokládala, že se jí tak podaří naplnit zprofanované heslo "naučte se ASP.NET za 21 dní". Tak to bohužel nefunguje – výsledkem byl zcela zmatený programátor a spousta vyhozených peněz.

Vzdělávání nezbytně nutně zahrnuje také možnost naučené vyzkoušet a uvést do praxe. Google je známý tím, že svým vývojářům dává jeden den v týdnu na to, aby vyvíjeli svoje vlastní projekty – a také tím, že z těchto "hobby" projektů se často vyvinuly úspěšné služby. Microsoft své vývojáře také podporuje v podobných věcech. I když třeba nemáte podobné zdroje, programátoři by měli mít možnost psát nějaké "vedlejší" projekty, kde je jenom minimálně omezována jejich volnost. Na těchto projektech si mohou relativně bezbolestně vyzkoušet nové koncepty, technologie a postupy, které třeba není možné hned nasadit do ostrého provozu "hlavního" systému, který vytvářejí.

Předsevzetí šesté: Budu mít na paměti, že programátor pracuje, i když zrovna nepíše kód

Programátor – minimálně dobrý programátor – nepracuje, jenom když má otevřené Visual Studio a píše kód. Program je totiž potřeba nejdříve vymyslet. S trochou nadsázky se dá říct, že jediný okamžik, kdy programátor nepracuje, je když píše kód – všechno už bylo vymyšleno a zbývá jenom to hodit do počítače. Mne osobně většina řešení napadá, když zrovna to Visual Studio otevřené nemám. Když zrovna čtu nějaký blog, prohlížím si vtipně udělaný web, jsem na procházce se psem, ležím v posteli nebo sedím na záchodě. Toho byste si měli být vědomi a nezmatkovat, když programátor "nic nedělá".

Dnešní vývoj reálně nespočívá v tom napsat co možná nejvíc kódu za co nejmenší časový úsek, ale často je žádoucí přesný opak – dlouho přemýšlet, jak napsat pár řádků, propojit co existuje a získat tak největší možnou výhodu s nejmenším počtem chyb.