Za posledních dvacet let se vývoj softwaru významně změnil. Původní model byl takový:

• Vytvořil se projektový plán
• Analytici sesbírali od klienta business požadavky
• Přetvořili je společně s klientem ve funkční požadavky
• Vše popsali ve specifikaci
• Tu předali k tvorbě architektury a technického designu seniorním vývojářům a architektům
• Poté se to předalo na vývoj a ten dlouhou dobu vyvíjel
• Software se testoval = testoval se interně a s uživateli
• Pak se software předal administrátorům, ti jej nasadili a provozovali (monitorovali).

A podobně to bylo s každou další změnou a rozšířením.

Popsaný model vývoje funguje někdo do teď. Stále je to vlastně takový základ, který dává smysl - něco se prozkoumá, navrhne se řešení, naprogramuje se to, a pak se to používá. Tento základní princip totiž asi jen tak nic nezmění (nebudeme nejprve programovat, abychom pak teprve zjišťovali, co kdo chtěl naprogramovat - i když tohle se také děje :-)). Jde především o to, v jaké míře a jak moc rigidně se tento model dodržuje.

Moderní přístup se snaží o větší flexibilitu, zrychlení celého procesu, dělání všeho v iteracích, více agilně. Míra, jak hodně se tento postup aplikuje striktně ve výše uvedeném postupu a jak moc je zjednodušený, agilní, záleží na prostředí. Například stále některé banky a velké instituce realizují projekty stále tímto postupem, kterému se říká waterfall, naproti tomu startupy a businessově exponované sektory (např. e-commerce) jdou agilnější cestou. V jejich případě je to dáno potřebou rychle reagovat na změny, které se na trhu odehrávají.

Problém tohoto rigidního postupu je totiž čas a flexibilita. Takový projekt se může vyvíjet roky, když vezmeme všechny fáze včetně analýz a nasazení. Za tři roky ale může dojít ke změně zadání - a většinou k němu také dojde. Zároveň na začátku lidé nedokáží popsat, co přesně chtějí a po spuštění projektu uživatelé zjišťují, že chtěli trochu něco jiného. To už je ale pozdě. Každá změna pak prochází stejným postupem. Právě tomuto modelu se říká waterfall, všechny fáze jdou jen směrem dopředu a zpětně proti vodopádu se k zadání vrací špatně.

Waterfall sám o sobě není špatný a v určitých sektorech a pro určité problémy dává smysl. Záleží na velikosti projektu, prostředí, schopnosti fungovat agilně apod. Waterfall je dnes brán jako sprosté slovo, ale reálně se s ním pracuje velmi často. A není to chyba dodavatelské firmy. Představte si veřejnou zakázku, kde si stát objedná projekt, neví ovšem, co dostane, a také neví, kolik ho to bude stát a má porovnat mezi sebou nabídky a vybrat nejlepší. Úředníci jsou ale mnohdy pod tlakem, navíc kontrolováni, proto si takový agilní přístup nemohou dovolit. Stejně tak velké firmy.

Jak celý proces udělat flexibilnější?

Agilita, metodologie Scrum:

• Stanoví se high level cíl, iteruje se v krátkých sprintech, např. týden, 14 dní. Výsledkem je nový kód, nový kus projektu. Vždy po konci části projektu se sejde zadavatel s vývojovým týmem a řeknou si, co by se mělo změnit a jak dál postupovat.
• Zrychlí se tím celý cyklus, dohodnutá věc je vidět brzy a ne až za 3 roky. Ale samozřejmě nemáte za 14 dní celý projekt, stejně se tedy nedá kompletně otestovat, pořád je ale lepší než čekat několik let a pak většinu vyhodit.

DevOps:

• Mění proces tak, že sloučí lidi, co dělají vývoj a provoz (adminy). Je to tedy Development and Operations, z toho zkratka DevOps. Developeři jsou potom takoví admini. Je to podobné jako u vývojových cyklů v agilitě (business je tam více spojený s vývojem, s analýzou), vše se tím urychlí. Nasadit projekt v nějaké těžkopádnější instituci trvá třeba i měsíce. Vývojáři mají hotovo a pak se čeká na adminy. Veškeré změny v konfiguraci si řeší admini, developeři do nich nevidí, všechno je příliš zdlouhavé. Naopak v DevOps to dělají developeři.
• Výhoda DevOps je, že vyvíjí software tak, jak si ho sami budou provozovat. Neberou to tak jako že „tohle bude na adminech“. Už první verze si někam nasazují a většinou podobně pokračují na produkčním (ostrém) prostředí. Takže to nenechávají nakonec adminům, ale celý ten výrobní chain softwaru se hned na začátku nastaví.
• Tomu pomáhají moderní nástroje pro kontejnerizaci, virtuální stroje a další. Velmi populárním nástrojem je Docker, který jakoby „zabalí“ celý software včetně celého operačního systému do jednoho balíku („image“) a ten je možno nasadit k sobě na laptop nebo třeba na produkční server a to bez jakýchkoliv změn v softwaru a operačním systému.
• Pomáhá tomu continuous integration, tedy automatizace nasazování. Vývojář vyvine, pošle kód a on se mu automaticky dostane na server. Tím se opět zrychluje celý proces. Zároveň se nový kód před nasazením na server otestuje pomocí automatizovaných testů bez zásahu člověka. Tím se ověří, že se v softwaru nic nerozbilo a ušetří se čas na dlouhé regresní testování celého systému.

Microservices, jiný styl architektury:

• Stále velmi populární téma, které umožňuje nepsat software jako obrovský monolit, ale rozdělit ho na samostatně žijící servisy (malé software na serveru), které si spolu povídají. Výhoda u velkých projektů: na servise pracuje vždy jeden tým, má know how, dokáže si to měnit. Když udělají změnu, ale nedojde ke změně API (tj. komunikace mezi jinými službami), pak to nikoho nemusí až tak zajímat. Tým dostane do produkce pár kliky novou verzi, mění si jenom svojí servisu. Opět se tím urychlí proces doručení.
• Není ovšem dobré to s microservices moc přehánět (tj. mít stovky malých servis, když to není v dané situaci nutné, například když pracují na všech službách stejní lidé, nepomáhá to výkonu systému). Celkově to totiž prodraží vývoj a náklady se naopak šetří až u větších systémů, případně systému s velkým požadavkem na výkon.

Styl, jakým se vyvíjí ve firmách software, se různí a je opravdu na široké škále všeho výše popsaného. Určitě není pravidlo, že každá firma musí vyvíjet agilně, striktně aplikovat DevOps a celý systém dnes přepsat do mikroservis. Je to ale cesta, kterou se již nějakou dobu vydává postupně celý svět a ve spoustě případů dává velký smysl.

Miroslav Fuksa Autor článku je zakladatel a ředitel vývojářské společnosti Coding Bear. Stojí za myšlenkou a rozvojem nástroje Bear Inspector, který analyzuje digitální stopu vývojových týmů a zlepšuje tak jejich efektivitu. Před založením Coding Bear zastával funkci IT ředitele společnosti Napka pod skupinou Rockaway a pracoval také na vývoji ve společnosti Oracle.