23.Feb.2009 at 23 | Jirka Khun
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?
