Praxe AAF s AI 3: HLA Blokace částky

Minule jsme doladili platbu strhnutím kreditu. Tentokrát přišel obchod s jiným nápadem: částku nestrhávat hned, ale jen ji – podobně jako u karty – zablokovat. Čistší, elegantnější. Návrh vypadal takhle:

Mobile Ticket Payment — varianta s blokací

Kino nabízí lístky.
Divák si je na webu rezervuje; kino spustí odpočet rezervace.
Kino vyzve diváka k platbě přes MTP a následnému zadání kódu, který po zaplacení dostane.
Divák u nás zaplatí kreditem; částku nestrhneme, pouze ji zablokujeme. Blokace má svůj kód a zároveň u nás běží její timeout.
Kód blokace vracíme divákovi.
Divák zadá kód blokace na stránce kina – buď v té samé session, nebo po novém otevření stránky.
Pokud v kině vypršel timeout (lístky již uvolněny), kino odmítne.
Pokud OK, kino nám s tímto kódem pošle žádost o stržení blokace (včetně své identifikace a částky.
Pokud blokaci nenajdeme, nebo částka nesedí nebo není ve stavu „čeká na stržení“ (např. vypršel u nás timeout), žádost odmítneme s odůvodněním.
Pokud vše sedí, připíšeme kinu částku blokace pro vyrovnání v uzávěrce.

Procesy spouštěné timeoutem
Vypršení timeoutu blokace u nás – změna stavu blokace a částka se tímto „vrací“ na kredit diváka.
Vypršení timeoutu rezervace v kině – rezervace (lístky) se v kině uvolní.

Pustili jsme na to AI Analytika – stejně přísně jako minule. A protože nápad působil „revolučně“, nechali jsme ho projet několika variantami scénáře. A přišlo příjemné překvapení: AI ho nezbořila. Scénář je v jádru správně – kód generujeme my, soukromí diváka se kinu neposílá, kontrola částky drží. Co AI udělala, bylo hlavně tohle: Ptala se, jestli to tak opravdu chceme.

Varianta s blokací totiž tiše mění několik původních požadavků: způsob platby, ověření zaplacení, odpovědnost za storno rezervace a také vypouští kód rezervace, který původní zadání obsahovalo. To není chyba scénáře – je to otázka na zadavatele: opravdu přepisujeme původní pravidla?

AI na začátku otevřela problém zásadní změny logikou otázky: „Není vztah mezi blokací a rezervací, opravdu to tak chcete?“ Scénář je v jádru správně, jen tohle je nutné promyslet a případně doplnit do řešení. My kód rezervace nepotřebujeme; pracujeme s blokací. Jenže kino ho potřebuje. Když mu divák přinese kód blokace (klidně z nového okna nebo u pokladny), kino musí poznat, ke kterým lístkům platba patří. Jeden kód nestačí – divák musí přinést dva kódy: kód blokace (náš – potvrzení o blokaci) a kód rezervace (kina – které lístky). Každá strana — tedy i kino — má totiž svůj Zákon zachování informace. Takže platí to nutně i pro kino, i když je to externí systém. A tady se to celé zlomilo: ve stabilním a robustním řešení musí divák pracovat se dvěma kódy, aby obě informace byly provázány stabilně a za všech okolností — např. nové session při zadávání kódu blokace na stránce kina = kino „neví“, ke které rezervaci divák blokaci zadává.

Posouzení varianty ze strany obchodu a vývoje:

Obchod: dva kódy = vyšší riziko záměny a horší zážitek pro diváka. Nechceme.
Vývoj: původní strhávání je starý, nečistě napsaný kód – rozprskaný, nezapouzdřený. Přepsat ho na blokaci by bylo drahé a rizikové. A je to hodně centrální agenda. Doporučujeme na to nesahat.

Závěr: zůstáváme u varianty se stržením a ověřením. Ne proto, že by blokace „nešla“ – navržený scénář logicky prošel a působí čistěji. Ale rozbor ho postavil proti reálné ceně. Obchod i vývoj se shodli, že první varianta (ta z minulého článku) je v této situaci lepším řešením.

Pointa

Všimněte si, co se stalo. AI tu nebyla nadšený akcelerátor typu „super nápad, jdeme do toho“. Naopak – provedla fundovanou revizi návrhu. A hlavně nepřeháněla. Neoznačovala otázky a rozhodnutí za chyby; většinou se jen ptala: „Je to tak myšlené?“ Přesně tahle brzda unáhlenosti často chybí, než se řekne „bereme to“. Žádný unáhlený Claptrap Driven Project.

Dobře oponovaný a dobře čitelný scénář umožňuje kvalifikované posouzení všech zúčastněných stran: váží se všechna hlediska – zde obchodní i vývojové – a nakonec vyhraje varianta, která nemusí být povinně „čistší“, ale schůdnější a obchodně přijatelnější. Bez přehledného a zkontrolovaného artefaktu typu Use Case Epic jsme jen v mlze emotivních debat. A má to i velmi přínosný vedlejší efekt: Tímto postupem se nenásilně zavádí i ve velké firmě jednotná metodika. Součástí dokumentace musí být protokol testu AI, ergo musí se vytvořit dokument Use Case Epic, ergo musí projít kolečkem zobrazeným v úvodním obrázku článku:
Nová varianta → AI se ptá → Vyhodnocení.

A ještě jedna poznámka k „výhře vývoje“ v tomhle příkladu: zavádět nové technologie neznamená zahodit staré principy. Využití AI neruší „staré dobré zásady“ čistého kódu: neignoruje SOLID ani DRY – spíš jsou tyto principy ještě víc vynucovány. Kdo píše skills pro AI, tak ví. A čistý návrh se vyplatí: kdyby to „staré strhávání“ bylo napsané čistě, změna by nebyla drahá a vývoj by to posoudil jako přesně cílenou změnu výměnou implementace polymorfního chování. (O čistém návrhu kódu mám dva seriály: Jak se tvoří čistý kód a Jaká jsou úskalí Quick & Dirty Code.)

Co bude dál

Po destilaci FP a výběru varianty HLA scénáře Use Case Epicu následuje v metodice Agilní analýzy s AI další krok: Vyhledání prvků Use Case 1. druhu ze scénáře Use Case Epic pomocí metody Cinknutí systému.

Jak se s tímto vyrovná AI? To si ukážeme v příštím článku.