Vývoj softwaru – největší mýty

Ačkoliv smyslem tohoto blogu není publikovat články z jiných webů, smysluplnost článku, na který jsem narazil, mě donutilo udělat jednu vyjímku. Článek, který se zabývá v ironickém slova smyslu největšími mýty vývoje SW, byl originálně publikován 31.1.2008 na webu: http://www.scream.cz/2008/01/31/vyvoj-softwaru-nejvetsi-myty

„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”.“

Co dodat…. Mnozí z vás se tomuto určitě jen zasmáli. Jak často se ovšem s tímto v praxi setkáte? Není velká část bodů vaším denním chlebem?

Bookmarking: