Scream

V poslední době vypadá situace trhu práce na velký nedostatek IT odborníků, zejména vývojářů. Pojďme si ukázat, proč je tomu tak a jaká řešení se nabízejí.

Architektura a konvence projektu

Stává se tradicí, že na projektu je minimálně jeden nedoceněný, zhusta zastávající vedoucí roli, neschopný programátor. Ten je na první pohled poznat – věnuje se všem možným aktivitám, jen ne opravdovému programování. Nejoblíbenější aktivitou těchto parazitů je určování mantinelů, zejména tzv. architektury. Ti jenž takový projekt nesou na svých bedrech a přesčasech jsou pak nuceni např.

• trávit čas přemýšlením nad každým písmenkem v názvu proměnné
• vytvářet soubory, které nejsou ke spuštění aplikace vůbec potřeba – interfacy, konfigurační a překladové soubor
• zvykat si na formátování kódu, které není danému programátoru vlastní – jako by na nějaké té mezeře záleželo
• rozlišovat, do které ze zbytečných vrstev psát výkonný kód
• udržovat jednotlivé soubory směšně malé, při tom je známým faktem, že kompaktní kód je lépe přehledný
• nepoužívat všechny vlastnosti daného programovacího jazyka – např. v Javě, už tak velmi syntakticky omezené, prskají nad přiřazením v podmínkovém příkazu a otrlejší i nad ternárním operátorem

Co tedy nutí vývojáře, ale zejména jejich nadřízené, k vynucování konvencí? Jednoznačně čas. Čím více zbytečných aktivit, tím více zaměstnanců, kteří pak chybějí na pracovním trhu, tím dražší projekty a tím vyšší platy.

Analýza, design a řízení projektu

Co je lidstvo lidstvem, existovala menšina produkující skutečné hodnoty a většina, která jen práci předstírala. Softwarové projekty jsou učebnicovým příkladem tohoto jevu. Není výjimkou stav kdy několika skutečným programátorům sekundují zástupy analytiků, konzultantů a manažerů. Přitom je pravdou, že několik schopných vývojářů by dokázalo projekt bez problémů zrealizovat. Je tedy důvod se zabývat jinými aktivitami, než skutečným vývojem?

• analýza – vždy je zřejmé, co má výsledná aplikace dělat, proč to opakovaně popisovat?
• to co nyní analytici považují za analýzu je stejně nepoužitelné, jedinou možností programátora je jí v tichosti obcházet a nebrat na vědomí
• se všemi zásadními požadavky se tak jako tak zákazníci obracejí přímo na programátory, proč je tedy nenechat vytvářet přímo kód – nic jiného stejně zákazníka neuspokojí
• řízení projektu je činnost, kterou jen manažeři maskují svou zbytečnost, určování co, kdy a jak mají vývojáři dělat začínající z nich jen obtěžuje a zdržuje – zkušení manažery ignorují
• zbytečné nástroje pro vedení požadavků – je dobrou praxí realizovat všechny nároky zákazníka okamžitě, proč je evidovat jinde než u jednotlivých vývojářů

Co tedy nutí vedoucí pracovníky k vynucování plánování a projektování programů? Jednoznačně čas. Čím více zbytečných aktivit, tím více zaměstnanců, kteří pak chybějí na pracovním trhu, tím dražší projekty a tím vyšší platy.

Testování

Stojí za povšimnutí, jak se v poslední dobou prosazují metodiky vývoje softwaru, které zdůrazňují důležitost automatizovaného testování. Kdo, nebo co, za tím humbukem stojí? Shrňme si fakta o testování a testovatelnosti programů.

Nebylo by tedy lepší testy vůbec nepsat? Zde jsou důvody, které jasně dokáží, že ano.

• testy nikdy nemohou pokrýt všechny požadavky zákazníka
• testy se musí přepisovat s každou změnou požadavků na produkt
• automatizované testy nikdy ani z části nenahradí testování zákazníkem
• při spadnutí testu mnohdy nelze rozhodnout, zda je chyba v aplikaci, či v testu samotném
• s každou sebemenší změnou zadání vývojář jednoduše upraví kód a nemusí upravovat nudné testy
• pokud se v projektu vyskytne chyba, je hned zřejmé, že k ní došlo v aplikaci – testy jsou vždy v pořádku, neexistují
• vývojáři nejsou zatěžováni další technologií, klesají náklady na školení
• není zbytečně zabíráno místo na discích vývojářských stanic, což zejména v případě mnoha malých souborů není zanedbatelná veličina

Co tedy nutí vývojáře, ale zejména jejich nadřízené, k vynucování psaní testů? Jednoznačně čas. Čím více zbytečných aktivit, tím více zaměstnanců, kteří pak chybějí na pracovním trhu, tím dražší projekty a tím vyšší platy.

Komentování kódu

Velcí guruové, kteří mají samozřejmě největší zájem na nedostatku programátorů, prosazují, aby vývojáři svůj kód zhusta komentovali. A to nejenom samotný výkonný kód, ale dokonce i rozhraní tříd a metod. Někteří se dokonce snaží tuto pošetilost povýšit na umění. Měli by si však uvědomit, co je v programování už mnoho let známé.

• dobrý kód je pochopitelný sám o sobě
• programátor je placený za tvorbu programů, za ostatní věci se platí spisovatelům
• je zvykem, že zdrojový text programu vytváří a upravuje jeden člověk, pokud není schopen se ve svém kódu vyznat, měl by zvážit změnu profese
• zadání toho, co má program dělat se často mění – není snad dostatek práce s přepisováním kódu – musíme ještě udržovat aktuální komentáře?
• místo na disku a zálohovacích médiích není zadarmo, i bez komentářů mají jednotlivé zdrojové soubory obvykle mnoho tisíc řádek

Co tedy nutí vývojáře, ale zejména jejich nadřízené, k vynucování psaní komentářů? Jednoznačně čas. Čím více zbytečných aktivit, tím více zaměstnanců, kteří pak chybějí na pracovním trhu, tím dražší projekty a tím vyšší platy.
Lze tento začarovaný kruh svazujících zásad rozetnout? Najdou se programátoři, kteří se nenechají ohlupovat nesmyslnými poučkami?

Nevím, jsem velmi pesimistický. Dnes už se lze setkat i s řadovými vývojáři, kteří, jsa ovlivněni výše popsanou propagandou, hlásají uvedené „modly“.