V dnešnej dobe nie je ťažké napísať softvér. Materiálov o tom, ako programovať, sa dá nájsť na internete mnoho, a veľa vývojových prostredí a platforiem je zadarmo. Napísať nejako softvér nie je naozaj ťažké. Čo je ťažké, je napísať softvér, ktorý sa aj o 5 rokov ďalšieho vývoja a opravy chýb bude vyvíjať rovnako jednoducho ako na začiatku. To je ozajstný ukazovateľ toho, či vie niekto len písať kód alebo tvoriť softvér. A základom dobrého softvéru je dobrá architektúra. Taká, ktorá sa vie meniť a pritom zachovať kľúčové vlastnosti. Dnes sa pozrieme na knihu Building Evolutionary Architecture.
Autori knihy to pojali ako rozhovor pri káve. „Poďme sa baviť o architektúre.“ Sadnú si s vami k šálke kávy do kaviarne a budú sa s vami rozprávať, od úvodu o čom to celé je, až ku ťažšej teórii, ktorá rieši podstatu veci.
A podstata veci je v okresanej podobne veľmi jednoduchá: Máte rozsiahly softvér, ktorý je postavený na nejakej architektúre. Je to projekt dlhodobý. Prostredie projektu (stav oboru IT) sa mení. Požiadavky na projekt sa menia. A architektúra to musí aj po tých X rokoch prežiť tak, aby vývoj a spravovanie nebola prechádza očistcom.
Ruku hore, kto pracoval na projekte s rozpadnutou architektúrou. Rozpadnutá architektúra je stav, kedy sa ešte sem-tam objavujú zvyšky toho ako to bolo naplánované, ale pomedzi to je kód plný skratiek, duplicít a záhadného kódu, ktorého sa bojí každý dotknúť. Rozpadnutá architektúra je vtedy, ak máte problém nakresliť zmysluplný diagram modulov/tried (aspoň taký čo nemá cykly) alebo opísať štruktúru aplikácie niekoľkými vetami.
Ja som bol na niekoľkých projektoch, ktoré mali rozpadnutú architektúru. Tých foriem je naozaj veľa (asi toľko ako foriem technologického dlhu, ktorý ide ruka v ruke s rozpadnutou architektúrou), ale samotný rozpad architektúry je vždy rovnaký. Nikdy to nie je prudké. Vždy to začína malým porušením pravidiel, malou skratkou v kóde, jednou nedokončenou prácou s TODO v kóde. A takéto malé porušenia sa strážia veľmi ťažko.
To si uvedomujú aj autori knihy, a preto prichádzajú s myšlienkou, že architektúru treba strážiť testovaním. Ideálne je, ak je to testovanie automatizované. Ak teraz neviete, čo si máte pod tým predstaviť, tak napríklad funkciu, ktorá vám bude kontrolovať, či nemáte v kóde cyklickú závislosť. Alebo či niekto neobišiel vrstvu pre prístup k databáze a zapisuje do nej priamo z prezentačnej vrstvy a pod.
Ale stráženie samotnej architektúry nie je jediné, čo vás v projektoch na dlhé trate musí a má trápiť. Okrem pravidiel architektúry ide aj o dodržanie je vlastnosti, ako je bezpečnosť alebo výkon. Aj na toto je dobré mať pripravené testovacie nástroje, ktoré strážia všetky zmeny a upozornia vás hneď ako dôjde k porušeniu.
Ale kniha Building Evolutionary Architecture nie je len o strážení vlastností. Obsahuje tiež katalóg architektúr, ktorý popisuje ich jednotlivé vlastnosti. Že je rozdiel, či pre svoj projekt zvolíte micro-kernel alebo SOA. Alebo aký je rozdiel medzi SOA a service-based architecture.
Opisuje tiež ako pristupovať k databáze, ktorá sa vyvíja tiež. Aké nástroje na to používať, ktoré vám umožnia prežiť aj veľa zmien v čase. Ďalej ukazuje klasické antivzory a pasce, do ktorých môže projekt spadnúť a ako sa im vyhnúť (ako napríklad staviť celý technologický stack na jedného dodávateľa). A nevyhýba sa ani téme ako pristupovať k organizovaniu tímu alebo projektu. Building Evolutionary Architecture nie je žiadna biblia. Ani hrúbkou – nie je to hrubá kniha – a ani by ste sa nemali doslova riadiť všetkým, čo tam nájdete. Je to veľmi dobrá kniha na zamyslenie sa pre každého architekta aspoň stredne veľkých projektov. Zmena na takých projektoch je niečo, čo nevyhnutne príde a vy sa s ňou musíte nejako vysporiadať. Buď ju môžete ignorovať a zapracovať len minimálne nutné riešenie, ale ona vás skôr alebo neskôr doženie vo forme problémov. Alebo ju akceptujete ako súčasť architektúry ale to tak, že vlastnosti architektúry ostanú zachované. Dosiahnuť to je kung-fu architekta a táto kniha je k tom nápomocný sprievodca.