Dnešní trendy softwarového vývoje hlásají rozmanitost. Každou chvíli „letí“ jiný Javascriptový Framework nebo knihovna, případně se alespoň v rámci nové verze poruší zpětná kompatibilita. Kdekdo by mohl podlehnout dojmu, že se tyto „veletoče“ týkají pouze front-endů. Nicméně i v enterprise back-end světě nás jistoty pomalu opouštějí. Nová verze JDK vychází každý půlrok, mnozí jsou stále zmateni a nevědí, kterou verzi mají vlastně použít (a za kterou platit), no a do neprostupného korporátního světa .Net a Javy se pomalu přesouvají dříve „nedůvěryhodná“ řešení jako NodeJS, Python, Ruby, atd. Mimo to už vlastní rozdělení na front-end a back-end pokulhává, jelikož se častěji bavíme o Serverless a mnohdy není ani jasné, co je ještě ten front-end a kde začíná back-end (anebo integrační vrstva, middleware, gateways, apod.).
Kulantně řečeno se nám z tohoto množství technologií a možností stává zoologická, kterou není jednoduché řídit nebo jenom bezpečně projít od začátku do konce. Aby toho nebylo málo, aktuální trendy hlásají mikroservisní přístup vždy a všude, i kdyby se mělo jednat o desktopový textový editor. Zde se samozřejmě bavíme o jisté nadsázce, nicméně při letmé analýze vnitřní architektury populárních textových editorů typu Atom nebo VSCode, které využívají Framework ElectronJS (tedy NodeJS + Chromium + JS/HTML), to již tak daleko od pravdy není. Tolik technologií a tolik možností. Lze v dnešním světě vůbec přežít jen s jejich omezeným počtem? Ano i ne…
Rozmanitost nebo konzervativnost?
Tuto a další otázky si musíme pokládat denně, a to jako jednotlivci, v rámci týmů, projektů i celých organizací. Pokud něco předepisují například interní IT pravidla, měly by se daným doporučením všichni řídit. Někdy se však nemusí jednat o úplně efektivní použití technologie, která se na tento typ úlohy hodí méně, než jiná (ovšem nepovolená). Proti tomu může jít vysoce efektivní práce na dílčí úloze v „trendy“ technologii, která se ovšem za pár let promění v noční můru.
Pojďme si dané popsat na příkladu dokonalého světa, ve kterém opravdu platí „the right tool for the job“. Vyřešíme problém rychleji pomocí Grails a scaffoldingu? Dobrá, pojďme použít tento framework. Je daný problém lepší řešit pomocí funkcionálního paradigmatu například ve Scale? Fajn, vzhůru do toho. No a zbyla nám nějaká část na práci s JSON daty? Tak pro to použijeme NodeJS a MongoDB, proč ne.
Dovolím si tvrdit, že pokud lidé v týmu dobře znají výše uvedené technologie, budou mnohem efektivnější a správný výsledek dodají nejenom dříve, ale také v dobré kvalitě. Nebudou se muset učit nové nástroje nebo studovat, jak daný problém, který by řešili přirozeně a efektivně v technologii A, vyřešit alespoň nějak v technologii B. Doposud je tedy vše ideální. Bohužel náš svět takový typicky není. Výše uvedený scénář funguje dobře do té doby, než naše systémy odložíme do „maintenance“ (mnohdy lze přeložit ve smyslu „pokud nejsou problémy, tak na to raději nesahejte“) a znalosti se postupně v týmu vytratí, systém zastará.
Jednoho dne pak nevyhnutelně přijde chvíle, kdy bude potřeba rychlý zásah a oprava, ale řešení bude najednou v jazyce, který buď nikdo nezná anebo se jedná o jakousi archaickou/specifickou verzi, případně framework. Tyto zkušenosti pak typicky vedou na logické řešení, kdy je předepsána tzv. technologická platforma, kterou musí každý nový systém dodržovat. Jako příklad takové platformy lze zmínit například následující populární kombinaci:
Na první pohled toto řešení nemá žádné vady. Jeden zásadní problém však lze nalézt i zde – je to nekompatibilita s dnešním rychle se měnícím světem. V současné době již opravdu nelze odpovědně předepsat technologii, která zaručeně vydrží 3 roky (nebo 5 a více let). Možná se za 3 roky bude stále jednat o Javu, .Net nebo Javascript (Python, …), ale určitě nebude vypadat stejně, případně (a to je ještě horší) bude dané řešení limitovat rozvoj vzhledem k (v dané době) aktuálním požadavkům.
Kde je tedy pravda, když předchozí odstavce naznačují, že ani jeden přístup není ideální? Odpověď je celou dobu skrytá v již zmíněné větě „the right tool for the job“, která říká mnohem více, než se na první pohled zdá.
Přístup k vývoji SW je základ
Pojďme si přiznat, že se občas snažíme řešit problémy, které neexistují, případně je hledáme tam, kde nejsou a možná ani nikdy nebudou. Pokud jsme otevřeni novým technologiím a nikoho v týmu nelimitujeme při jejich výběru (jen v případě, že dané řešení samozřejmě dává smysl z pohledu architektury, designu, atd.), nesmíme zapomenout na údržbu, kde náš software bude typicky trávit většinu času. V té možnosti je alfa a omega celého problému. Pokud víte, že se tak stane ve většině případů, a váš softwarový produkt bude nejlépe bez jakéhokoliv zásahu fungovat ideálně dalších 5 let, na technologickou rozmanitost rovnou zapomeňte. Nastavte jeden směr a vyžadujte ho. V opačném případě se dříve nebo později (ale spíš dříve) dostanete do v předchozím odstavci nastíněné situace s nedostatečnou znalostí svého software a nezbývá než popřát hodně štěstí a vytrvalosti. Zjednodušeně řečeno nelze být progresivní tam, kde progrese končí s nasazením do produkce.
Pokud však víte, že váš software budete rozvíjet neustále, protože je součástí vaší společnosti, můžete si dovolit téměř cokoliv. Ať už technologie přijdou nebo zmizí, budete díky neustálému kontaktu s řešením disponovat detailní znalostí všech aspektů a hlavně budete moci technologie postupně nahrazovat, vylepšovat nebo si je ponechat. Základem zde samozřejmě je, že software aktivně neustále rozvíjíte, a díky tomu se můžete držet takříkajíc na špici. No, a pokud zjistíte, že daný software již žádné benefity nepřináší nebo ho váš business nepotřebuje, tak se ho zbavíte – jelikož proč udržovat něco, co mi nic nepřináší?
Dalším populárním trendem dneška je inspirovat se u těch “nejlepších”. To rozhodně není vůbec špatně! Akorát ti nejlepší možná řeší úplně jiný business, mají jiné požadavky zákazníků (a pro ně specificky vyvinuté aplikace) a hlavně do IT investují kontinuálně úplně jiné peníze (násobně větší, aby nedošlo k mýlce). Velmi často se opakují věty typu „Budeme vyvíjet jako Spotify“, případně „Chceme být technologicky na výši jako Netflix nebo Airbnb“. Letmý pohled na známé stránky Stackshare.io mnohé zláká k úsudku, že rozhodnutí je nutné udělat teď, nebo nikdy – a ideálně změnit všechno naráz. Problém je však v tom, že přesně takto to ti nejlepší nedělali a ani nedělají. Inspirace je tedy určitě žádaná a správná, akorát se vždy musí zasadit do odpovídající reality.
Technologie jsou pouze nástroj, pomocí kterého můžeme dojít k požadovanému cíli. Cíl v podobě slepého použití technologií ale smysl nedává. Pozornému čtenáři jistě neuniklo, že předchozí odstavce v mnoha ohledech zmiňují nebo přímo vyžadují principy DevOps a agilního vývoje. Ano, to je samozřejmě pravda, nicméně tyto termíny byly pro účely článku vynechány záměrně, protože se často značně nadužívají a vytrácí se jejich originální význam (na některých konferencích můžete například směle zaměnit slova jako agile za digital a nikdo se nad tím ani nepozastaví).
Stejně jako u technologií bychom se totiž měli vždy řídit zdravým inženýrským pohledem, mít jasnou vizi, cíle a pro jejich naplnění zvolit správné nástroje i postupy. Chovat se tak, aby řešení mělo šanci fungovat v naší organizaci a nevolit jej jen proto, že ho již používají „všichni“ a „píše se o tom na Internetu“. O ničem jiném totiž vývoj software nebyl, není a dovolím si tvrdit, že ani nebude.
Autor: Michal Petřík