Architektonické přístupy | Technologický blog

TECHNOLOGICKÉ BLOGY Z PROSTŘEDÍ ANASOFTU

V dnešní části technologického blogu budeme hovořit s jedním z návrhářů společnosti ANASOFT, Martinom Vozárom. Ten má více než dvacetileté zkušenosti s vývojem aplikací na míru od těch malých až po velké enterprise řešení. Řeč bude o distribuovaném přístupu k tvorbě aplikací a jeho specifikách.

Jak jste v tomto případě postupovali a proč?

Pro lepší představu je důležité uvědomit si, co všechno taková aplikace potřebuje dělat. V prvé řadě potřebuje z externího systému získat údaje na zpracování. Tyto si potřebuje uložit do vlastní lokální databáze a následně nad nimi spustit pracovní procesy, ke kterým se váže i uživatelské rozhraní, kterým obsluha systém ovládá. A následně je potřebné zpracované údaje vrátit zpět do systému, z kterého pochází.

Z povahy aplikace vyplývá, že dělá množství odlišných operací. Integrační resp. interface-ové operace jako získání dat z externího systému a jejich vrácení zpět, backendové operace související s lokálním uložením a zpracováním údajů a frontendové operace uživatelského rozhraní pro zadávání pokynů obsluhy a prezentování výsledků.

A to si vyžaduje distribuovaný přístup?

Nevyžaduje, ale v tomto případě to byla jedna z možností a ukázala se jako dobrá. Samozřejmě, bylo by možné technické řešení, kterým by vznikla jedna velká monolitická aplikace. V tomto případě jsme se však rozhodli vytvořit několik samostatných aplikací, z kterých každá plnila velmi specifickou úlohu. Jednotlivé aplikace tak mezi sebou fungovali na základě jakýchsi signálů.

Můžeš uvést konkrétnější příklad?

Například aplikace, která je zodpovědná za zpětné odeslání údajů do původního velkého systému funguje tak, že v pravidelných intervalech sleduje obsah dohodnutého adresáře, a pokud v něm najde soubory v dohodnutém formátu, zpracuje je a odešle do původního systému. Takovýto přístup má několik výhod.

Bylo by možné technické řešení, kterým by vznikla jedna velká monolitická aplikace. V tomto případě jsme se však rozhodli vytvořit několik samostatných aplikací, ze kterých každá plnila velmi specifickou úlohu. Jednotlivé aplikace tak mezi sebou fungovali na základě jakýchsi signálů.

Které jsou ty nejdůležitější?

Začíná to už při samotném vývoji. 

Takto samostatně navrhnutá aplikace se dá implementovat nezávisle od zbytku systému. Může na ní pracovat vývojář, který nepotřebuje znát žádné další části systému.

Stačí mu vědět, že má sledovat obsah adresáře a jakým způsobem údaje zpracovat a přenést do externího systému. Umožňuje to tedy paralelní vývoj nad celým řešením.

Další výhodou je, že kód takových řešení zůstává poměrně čistý a dobře čitelný. Aplikace na zpracování souborů se zabývá pouze tím, co je její náplní a ostatní části systému, ostatní aplikace, se o vstupně-výstupní operace a napojení na okolní systémy nemusí vůbec zajímat.

Takový přístup zjednodušuje údržbu celého systému a také hledání chyb. Pokud například neprocházejí výsledná data zpět do externího systému, je logické začít hledat chybu právě v aplikaci, která odpovídá za jejich přenos.

V případě, že externí systém neběží, ovlivňuje to právě jen tuto jednu aplikaci a ostatní části systému mohou běžet nezávisle dál. Navíc pokud se najde chyba v aplikaci, která předává data do externího systému, stačí opravit kód právě této jedné aplikace a tuto přetestovat a nasadit. Ostatní části systému, ostatní dílčí aplikace, zůstávají beze změny.

Za zmínku také stojí vyšší souběžnost vývojářských prací a možnost využívat více specifické odbornosti vývojářů. Ne každému vývojáři stejně dobře sedí každý druh vývojářské práce. Někdo se lépe uplatní při tvorbě uživatelského rozhraní, a někdo naopak při databázových operacích či rozhraních mezi různými systémy. Vývoj jedné velké aplikace by znamenal, že různí vývojáři sdílejí společný kód a musí se v něm alespoň v základu orientovat. I v částech, které se jejich práce netýkají. Při samostatných aplikacích má každý své vlastní "hřiště" a důležité je pouze správně nastavit propojení jednotlivých částí řešení.

V případě, že externí systém neběží, ovlivňuje to právě jen tuto jednu aplikaci a ostatní části systému mohou běžet nezávisle dál. Navíc pokud se najde chyba v aplikaci, která předává data do externího systému, stačí opravit kód právě této jedné aplikace a tuto přetestovat a nasadit.