Spedice: Přestavba za plného provozu

Od posledního článku o cestě Spedice uběhla nějaká doba. Navenek aplikace stále dělá to, k čemu vznikla: propojuje provozovny, manažery, docházku, objednávky, faktury a další každodenní agendu. Uvnitř se však změnila téměř k nepoznání.

Vývoj mezi verzemi 1.0.8.3.4 a 1.0.8.6.9 nebyl jen další sérií drobných úprav. Šlo o rozsáhlou přestavbu technických základů, která probíhala za skutečného provozu.

Systém přitom musel dál sloužit lidem, kteří neřeší použité frameworky ani architekturu. Potřebují ráno otevřít aplikaci, objednat zboží, zapsat docházku nebo zpracovat fakturu — a potřebují, aby to fungovalo.

Starý systém, nové základy

Spedice vznikala postupně podle skutečných potřeb. Každá další funkce řešila konkrétní problém, ale roky vývoje zároveň vytvořily množství přímých PHP stránek, historických routerů, společných globálních stavů a různých způsobů vykreslování.

Taková aplikace může dlouho fungovat dobře. S rostoucím počtem modulů však začne být každá změna dražší a riskantnější. Úprava jednoho místa může nečekaně zasáhnout jiné a hledání chyby připomíná cestu vrstvami historie projektu.

Proto začal postupný přechod na nový aplikační základ. Požadavky nyní procházejí jednotným HTTP jádrem, routování převzaly komponenty Symfony a jednotlivé stránky se přesouvaly do samostatných controllerů. Uživatelské rozhraní se současně sjednotilo pomocí Twig šablon.

Nešlo o jednorázové přepsání všeho. Takový postup by u živého systému přinesl příliš velké riziko. Moduly se převáděly postupně: Retail, Faktury, Manager, Docházka, Warehouse, Logistics, OMDC, administrační nástroje a nakonec také rozsáhlý modul Enigma.

Po určitou dobu tak vedle sebe existoval starý i nový svět. Teprve když nové cesty zvládly skutečný provoz, bylo možné odstranit přechodové vrstvy.

Objednávky, které odpovídají skutečné práci

Největší množství praktických změn se týkalo objednávek provozoven. Právě tady je nejlépe vidět rozdíl mezi funkcí, která technicky existuje, a nástrojem, se kterým se dá pohodlně pracovat každý den.

Vznikl nový přehled objednávek, schvalovací pracoviště pro manažery a souhrnná tabulka připomínající Excel. Manažer vidí jednotlivé produkty proti všem provozovnám, může porovnávat sklad, návrh i konečné objednané množství a řešit odchylky bez neustálého přepínání mezi stránkami.

Skutečný provoz ale rychle ukázal další podmínku: přibližně devadesát procent práce probíhá na tabletech. Rozhraní navržené jen podle stolního počítače proto nestačí.

Tabulka musí jít přirozeně posouvat dotykem, první sloupec s produktem musí zůstat viditelný a zároveň je nutné ukotvit horní řádek s názvy obchodů. Jinak člověk u delší objednávky jednoduše ztratí přehled o tom, pro kterou provozovnu právě zadává množství.

Výsledkem je dvouosá objednávková matice s ukotvenými záhlavími, jemnějšími posuvníky a rozměry přizpůsobenými tabletu. Vedle ní zůstal také mobilní pohled určený pro práci po jednotlivých provozovnách.

Podobně praktické byly i zdánlivé maličkosti: možnost zadat při odpisu pečiva skutečnou nulu, správně umístěná tlačítka pro dokončení objednávky, obnovení rozpracovaného konceptu nebo návrat objednávky zpět konkrétní provozovně.

Jednotlivě jde o malé změny. V každodenní práci ale rozhodují o tom, zda systém pomáhá, nebo překáží.

Offline není výjimka

Provozovny nemohou spoléhat na to, že připojení bude vždy dokonalé. Proto vznikl offline přívětivý objednávkový postup založený na lokálním úložišti prohlížeče.

Rozpracovaná objednávka se neztratí při výpadku sítě a po obnovení spojení může pokračovat v cestě k manažerovi.

Offline režim zároveň změnil způsob, jakým je potřeba přemýšlet o stavu objednávky. Nestačí rozlišovat jen hotovo a nehotovo. Systém pracuje s konceptem, připraveným konceptem, průběhem zpracování, předáním manažerovi, schválením a odesláním dodavateli.

Každý krok musí být srozumitelný uživateli a současně bezpečný při opakovaném požadavku nebo návratu na předchozí obrazovku.

Faktury, OCR a méně ruční práce

Velkou proměnou prošel také fakturační modul. Přibylo zpracování nahraných dokladů, OCR, párování faktur, náhledy souborů a exportní nástroje pro bankovní dávky KPC a IKM.

OCR není kouzelné tlačítko, které vždy vrátí dokonalý výsledek. V reálném světě přicházejí různé formáty, fotografie, PDF soubory, horší kvalita tisku i omezení hostingu.

Bylo proto nutné doplnit kontrolované záložní postupy, čisté JSON odpovědi, diagnostiku chyb a bezpečné zacházení se soubory.

Podobný princip se později využil také u produktových etiket. Systém dokáže připravit rozpoznání názvu, složení nebo alergenů, ale konečné rozhodnutí zůstává na člověku. Automatizace zde nemá nahrazovat kontrolu — má odstranit zbytečné přepisování.

Docházka od terminálu až po plánování

Docházkový modul se posunul od prostého seznamu záznamů k širšímu pracovnímu nástroji.

Přibyl přehled směn všech provozoven, tabulkové plánování, export do Excelu, tisk do PDF a opravy dotykového posouvání. Manažer tak může pracovat s rozpisem provozoven jako s jedním celkem, aniž by musel každou pobočku otevírat samostatně.

Současně bylo potřeba myslet na výkon. Stav docházkových terminálů se proto ukládá do krátkodobé cache, aby každé otevření přehledu neopakovalo stejnou drahou práci.

Právě podobné nenápadné optimalizace rozhodují o tom, zda aplikace obstojí i na sdíleném hostingu.

Přihlášení, relace a bezpečnost bez zbytečných překážek

Přestavba se dotkla také bezpečnostní vrstvy. Přihlášení, kontrola IP adres, stav účtu, jedinečné uživatelské relace i povinná změna hesla dostaly oddělené služby a jasnější pravidla.

Zvláštní pozornost si vyžádalo automatické vypínání účtů. Funkce, která je užitečná jen v určitých situacích, nesmí začít rozhodovat sama bez výslovného zapnutí. Její spuštění je proto svázáno s konfiguračním přepínačem a pokryto samostatnými testy.

Také povinná změna hesla při prvním přihlášení se vyvíjela podle zpětné vazby. Uživatel může nové heslo nastavit, ale systém dokáže respektovat i rozhodnutí ponechat původní.

Bezpečnost má uživatele chránit, ne je bez vysvětlení uzamknout mimo aplikaci.

Aktualizace, které se dají opakovat

S rostoucím rozsahem změn přestal stačit updater založený jen na kopírování souborů. Aktualizace nyní podporují synchronizaci databázového schématu, kontrolovaný seznam operací i režim, který provede pouze souborovou část.

Důležitá je především opakovatelnost. Pokud se instalace přeruší nebo je potřeba balíček nahrát znovu, výsledek musí být stejný.

Aktualizace nesmí záviset na náhodném pořadí souborů ani na tom, zda některý krok proběhl už předtím.

Když produkce řekne pravdu

Sebelepší lokální testování nenahradí okamžik, kdy systém začne používat více provozoven současně.

První produkční den verze 1.0.8.6.9 proto nebyl slavnostním koncem vývoje, ale další částí ověřování.

Ukázaly se chybějící odkazy, neúplně nahrané šablony, deaktivované účty, formulář odmítající nulovou hodnotu i tabulka, která se na tabletu nechovala přirozeně. Objevila se také první odpověď 503, která znovu připomněla limity sdíleného hostingu a potřebu omezovat pomocné databázové zápisy.

Tyto problémy nejsou důkazem, že přestavba neměla smysl. Naopak ukázaly hodnotu nové struktury.

Chybu bylo možné dohledat ke konkrétnímu controlleru, šabloně nebo službě, opravit ji na jednom místě a doplnit testem, který zabrání jejímu návratu.

Od ručních kontrol ke skutečné testovací síti

Na konci stabilizace proběhla kompletní kontrola projektu.

Vedle běžných unit testů se spustily HTTP a integrační testy, syntaktická kontrola PHP, produkční frontendový build a transakční CRUD testy nad formulářovými tabulkami lokální databáze.

Výsledkem bylo 291 testů a 1 617 ověření bez jediné chyby.

Samotné číslo samozřejmě nezaručuje, že se už nikdy nic nepokazí. Znamená ale, že známé pracovní postupy, bezpečnostní pravidla, routování, vykreslování i databázové operace mají kontrolní síť, která před dalším nasazením zachytí velkou část regresí.

Přestavba, kterou uživatel nemá poznat

Největším úspěchem podobného refaktoringu není nový framework ani počet přepsaných souborů. Je jím chvíle, kdy uživatel otevře aplikaci a jednoduše pokračuje v práci.

Pod povrchem dnes Spedice stojí na výrazně čitelnějších základech. Má jednotné routování, oddělené controllery, Twig šablony, bezpečnostní pipeline, opakovatelnější aktualizace a podstatně širší testovací pokrytí.

Nad povrchem se změnila hlavně tam, kde to lidé skutečně potřebovali: na tabletu, při výpadku připojení, během objednávání, ve schvalování, u docházky nebo při práci s fakturou.

Co se chystá dál

Přestavba technických základů nebyla cílem sama o sobě. Vytvořila prostor pro funkce, které by se do původní architektury přidávaly stále obtížněji.

Jedním z dalších kroků budou vlastní e-mailové schránky pro jednotlivé uživatele a interní chat mezi provozovnami. Komunikace tak nebude rozptýlená mezi osobními e-maily, telefony a externími aplikacemi, ale bude přímo spojená s konkrétními pobočkami, uživateli a pracovními procesy.

Rozšířením projde také Kanban. Úkoly nebude možné jen zapisovat a sledovat, ale také předávat mezi manažery a provozovnami. Z jednoduchého seznamu se tak postupně stane skutečný nástroj pro řízení práce napříč firmou.

Centrální zvoneček

Důležitou součástí dalšího vývoje bude centrální informační zvoneček v horní liště aplikace. Jeho úkolem nebude zobrazovat další obecné notifikace, ale soustředit na jedno místo informace, které vyžadují pozornost.

Uživatel zde podle svého oprávnění uvidí například:

nové e-maily,
přidělené a blížící se úkoly,
objednávky čekající na zpracování,
nové zprávy v interním chatu,
nahrané faktury,
problémy a excesy v docházce,
kalendářní připomínky, které už jsou součástí systému,
fotografie čekající na kontrolu,
informace získané z ARESu,
informace ze systémů Veterinární správy.

Cílem je, aby důležité události nebyly schované uvnitř jednotlivých modulů. Po přihlášení musí být okamžitě vidět, co se změnilo, co čeká na rozhodnutí a kde vznikl problém.

A protože podnikový systém nemusí být jen nekonečný seznam povinností, ve zvonečku se možná jednou objeví i to nejdůležitější: upozornění, že zbývá pět minut času na měsíční partii ELO. Když už má člověk mezi objednávkami, fakturami a docházkou chvíli klidu, může si alespoň zahrát šachy.

Logistika postavená znovu

Samostatnou velkou oblastí bude nové vybudování modulu Logistika. Nepůjde pouze o evidenci jízd, ale o propojený pracovní systém zahrnující mapy, plánování tras a výpočet jejich délky.

Součástí by mělo být elektronické odesílání CMR dokumentů, sledování pohybu palet a napojení na skladové hospodářství. Systém tak bude vědět nejen to, kam má řidič jet, ale také zda konkrétní paleta už přijela, byla naložena nebo sklad opustila.

Počítá se také s importem faktur a CMR dokumentů přímo od řidičů, přepočtem paletových míst a kontrolou nakládky z více míst. Logistika se tím propojí s fakturací, skladem i evidencí dokumentů a odstraní další část ručního předávání informací.

Skladové hospodářství a masové zpracování

Další rozsáhlou oblastí bude skladové hospodářství. To má sloužit nejen běžnému skladu, ale také připravovanému modulu kafilerního a masového zpracování.

Systém bude sledovat pohyb, umístění a historii skladovaných položek, jejich návaznost na dopravu a postupné změny stavu. Počítá se s historií indexací, kontrolou obsazenosti i generováním faktur podle využité skladové kapacity.

Díky propojení s Logistikou bude možné sledovat celý proces od příjezdu vozidla přes vykládku a uskladnění až po další zpracování nebo expedici. Stejná data tak nebude potřeba opakovaně přepisovat v několika různých evidencích.

A ještě enigmaTerminal

To všechno se týká dalšího vývoje samotné Spedice. Vedle ní ale postupně vzniká také enigmaTerminal — samostatná část ekosystému, která rozšiřuje možnosti práce mimo klasické webové rozhraní.

Jeho příběh by se do tohoto článku už nevešel. A upřímně, zaslouží si vlastní pokračování.