Jak stavíme systémy tak, aby vydržely 5 let. A proč je přesto po pěti letech měníme

A zpravidla se změní také samotná firma.

Internetový projekt proto nelze rozumně navrhovat s představou, že jej dnes spustíme a následujících deset let na něj nikdo nesáhne. Stejně tak ale není příliš šťastné po třech či pěti letech zjistit, že jedinou možností dalšího rozvoje je všechno zahodit a začít znovu.

Při návrhu nových systémů se proto snažíme obě věci oddělit.

To, co se přirozeně mění, musí být možné měnit relativně snadno. To, co tvoří základ systému, by naopak mělo vydržet podstatně déle.

Pět let starý web nemusí být starý systém

Na první pohled může toto tvrzení působit trochu zvláštně.

Pokud se podíváme na webové stránky vytvořené před pěti nebo deseti lety, jejich stáří mnohdy poznáme během několika sekund. Jinak velké fotografie, jiné rozložení stránky, jiný způsob navigace, jiné písmo a často také poněkud odlišná představa o tom, co uživatel od webu očekává.

To ale ještě neznamená, že musí být stejně zastaralé všechno, co se nachází pod jejich povrchem.

Databáze zákazníků, objednávky, dokumenty, obchodní logika nebo napojení na další systémy mohou bez problémů sloužit dál.

A právě s touto představou se snažíme systém stavět už od začátku.

Fasádu můžeme změnit, základy bychom raději nechali na místě

U jednoduchého prezentačního webu není případná kompletní přestavba žádnou katastrofou. Situace je však poněkud jiná u systému, který firma několik let skutečně používá.

Za tu dobu v něm mohou vzniknout desetitisíce objednávek, stovky zákaznických účtů, dokumenty, historie komunikace a především procesy, na kterých je firma do určité míry závislá.

Vyhodit takový systém pouze proto, že potřebujeme modernější uživatelské rozhraní, by bylo přinejmenším poněkud nešťastné.

Proto se snažíme oddělovat jednotlivé části aplikace tak, aby změna jedné nemusela automaticky znamenat změnu všech ostatních.

Uživatelské rozhraní může komunikovat s aplikační částí prostřednictvím API, aplikační logika pracuje s datovou vrstvou a jednotlivé služby mohou mít vlastní jasně definovanou úlohu.

Ne proto, že čím více odborných výrazů v technickém návrhu použijeme, tím modernější systém vznikne.

Důvod je podstatně praktičtější.

Až budeme za několik let něco měnit, potřebujeme vědět, kam sáhnout, a pokud možno nerozbít všechno okolo.

Proč právě Python a Django?

Technologie vybíráme trochu jinak, než se někdy vybírají mobilní telefony.

Nezajímá nás příliš, zda je konkrétní framework právě letos největším hitem technologických konferencí. Podstatnější je, zda má za sebou dostatečně dlouhou historii, aktivní vývoj, rozumnou podporu a zda existuje značná pravděpodobnost, že s ním budeme schopni pracovat také za několik let.

Proto pro značnou část aplikačních systémů používáme Python a Django.

Django není nový framework. A právě to lze v tomto případě považovat spíše za výhodu.

Má dlouhodobě ustálené principy, velmi dobře řeší práci s databází, uživatelskými účty, oprávněními a řadu bezpečnostních mechanismů poskytuje přímo jako součást frameworku.

Samozřejmě ani použití Django samo o sobě nezaručuje kvalitní aplikaci. Špatný systém lze napsat prakticky v libovolné technologii.

Dává nám ale poměrně pevný základ, na kterém lze dlouhodobě stavět.

API není kouzelné slovo

U složitějších projektů zpravidla oddělujeme aplikační část od uživatelského rozhraní a komunikaci mezi nimi řešíme prostřednictvím API.

Zní to technicky, ale praktický důvod je poměrně jednoduchý.

Představme si například firemní systém, který dnes používají zaměstnanci prostřednictvím webového prohlížeče. Za dva roky vznikne požadavek na mobilní aplikaci a později potřebujeme některá data zpřístupnit dalšímu firemnímu systému.

Pokud je vše navrženo jako jeden obtížně rozdělitelný celek, začíná být každá podobná změna problém.

Pokud máme jasně definovanou aplikační část a způsob, jakým s ní ostatní části komunikují, můžeme vedle současného webu postavit například nové uživatelské rozhraní, aniž bychom kvůli tomu museli přepisovat správu objednávek, zákazníků a vše, co už několik let funguje.

Neznamená to, že každý web musí mít samostatné API a pět serverů. U jednoduchého firemního webu by to byla spíše ukázka toho, jak jednoduchý problém vyřešit zbytečně složitě.

Technická architektura má odpovídat tomu, co systém skutečně potřebuje.

Docker aneb aby server nebyl archeologické naleziště

Systém samozřejmě netvoří pouze zdrojový kód.

Potřebuje konkrétní verzi programovacího jazyka, databázi, knihovny a řadu dalších součástí. A všechny tyto věci se postupem času mění.

Pokud na jednom serveru provozujeme více aplikací různého stáří, můžeme se poměrně snadno dostat do situace, kdy jedna potřebuje novější verzi určité technologie a druhá naopak funguje pouze se starší.

Docker nám umožňuje jednotlivým aplikacím vytvořit vlastní, poměrně přesně definované prostředí.

Pět let stará aplikace tak nemusí diktovat podmínky aplikaci, kterou jsme vytvořili minulý týden. A naopak aktualizace nového projektu nemusí automaticky ohrozit projekt starší.

Z dlouhodobého hlediska je právě tato určitá izolace jednotlivých systémů podstatně zajímavější než skutečnost, že je dnes Docker populární technologie.

A proč pořád používáme Bootstrap?

Protože funguje.

Možná poněkud málo vzrušující odpověď, ale z hlediska dlouhodobého projektu poměrně podstatná.

Bootstrap používáme řadu let a jeho základní princip zůstává stále velmi podobný. Řeší responzivní rozložení stránky, poskytuje předvídatelné chování jednotlivých prvků a především nám nebrání vytvořit vlastní grafický vzhled.

Web tedy nemusí vypadat „jako Bootstrap“.

Je to konstrukce pod povrchem, nikoliv grafický návrh.

Za několik let můžeme změnit barvy, typografii, velikosti jednotlivých prvků nebo prakticky celý vzhled webu, aniž bychom kvůli tomu museli měnit způsob, jakým funguje jeho aplikační část.

A přesně to od podobného nástroje očekáváme.

Proč tedy po pěti letech něco měnit?

Protože svět kolem systému se za pět let změnil.

Uživatelé používají jiná zařízení. Firma nabízí jiné služby. Z původně důležité části webu může být okrajová záležitost a naopak něco, co při vzniku projektu prakticky neexistovalo, může dnes tvořit podstatnou část podnikání.

Máme navíc jednu věc, kterou jsme při návrhu nového projektu neměli.

Několik let skutečných zkušeností.

Víme, co uživatelé používají, kde mají problémy, které funkce se ukázaly jako zbytečné a co naopak postupně vznikalo trochu živelně a zasloužilo by si dát do pořádku.

Proto má po několika letech smysl projekt znovu projít, upravit jeho grafickou podobu, způsob ovládání, strukturu obsahu a samozřejmě také technologie, u kterých je modernizace potřebná.

To ale není totéž jako celý systém zahodit.

Starý systém není ten, který vznikl před pěti lety

Za skutečně zastaralý systém nepovažujeme automaticky systém starý.

Problémem je spíše systém, který už nelze rozumně měnit.

Pokud každá nová funkce vyžaduje zásah do pěti dalších částí aplikace, aktualizace jedné knihovny rozbije půl projektu a nikdo se neodvažuje upravit určitou část kódu, protože „na to se raději nesahá“, máme technický problém bez ohledu na datum jeho vzniku.

Naopak aplikace vytvořená před pěti či deseti lety může být stále velmi dobře použitelným základem, pokud byla průběžně udržována a její architektura s dalším vývojem alespoň trochu počítala.

A právě o to se při návrhu snažíme.

Neumíme samozřejmě předpovědět, jak bude internet vypadat za deset let. A bylo by poněkud odvážné tvrdit opak.

Můžeme ale systém postavit tak, aby kvůli každé změně nebylo nutné začínat znovu od nuly.

Dobrý systém totiž podle nás není ten, na který se deset let nemusí sáhnout.

Je to systém, na který se i po deseti letech ještě dá sáhnout, aniž bychom toho vzápětí litovali.