Mobilní bankovní aplikace při spuštění obvykle fungují. Problémy přicházejí později.

Když projekt přežije ty, kteří ho postavili

Bankovní aplikace jsou rozsáhlé projekty s dlouhou životností. Je přirozené, že se v průběhu vývoje lidé střídají. Spolupracuje více týmů, každý zodpovědný za část systému. Výzva je jediná: zajistit, aby projekt nepřišel o know-how pokaždé, když někdo odejde.

‍

"Nastavte projekt tak, aby know-how nezůstávalo v hlavách lidí, ale v samotném projektu."

‍

Velkou část toho řeší dokumentace. Ale ne jen Confluence. Dokumentace na úrovni kódu, která vysvětluje, proč bylo něco zvoleno a proč ne. Komentáře to-do a fix-me s datem, důvodem a odkazem na ticket. Popis UX logiky napsaný pro vývojáře, který ho bude číst za dva roky. Design systém, který někdo dokáže skutečně použít, aniž by musel volat původnímu autorovi.

‍

Nic z toho není atraktivní práce. Ale v projektu, který běží roky přes více týmů, je to přesně to, co odděluje strukturované dodávání od neustálého předělávání.

‍

Architektura, která si svou složitost zaslouží

Každé architektonické rozhodnutí z prvního roku vás o tři roky později buď ochrání, nebo omezí. Většina týmů to zjistí až ve chvíli, kdy se vývoj začne zpomalovat a nikdo nedokáže vysvětlit proč.

‍

„Neexistuje jedna správná architektura. Každá firma a každý vývojář má svou vlastní. Co milujeme my, je clean architecture."

‍

Clean architecture vrstvená od kódu závislého na systému k systémově nezávislému. Praktický přínos je jednoduchý: když potřebujete vyměnit síťovou knihovnu, změníte síťovou vrstvu. Nic dalšího se nerozbije.

‍

Pokročilá modularizace to posouvá dál. Standardně pracujeme s více než 100 moduly, což nám dává přesnou kontrolu nad tím, co je v systému viditelné a co zůstává interní.

‍

Pro sdílení business logiky napříč Androidem a iOS používáme Kotlin Multiplatform. Chování zůstává konzistentní. Opravy chyb se zpravidla aplikují jednou, v jednom pull requestu. Čas vývoje klesá zhruba o 40 %. UI ponecháváme platformově specifické, protože tam potřebujete plnou kontrolu nad animacemi a nativním pocitem, který uživatelé očekávají.

‍

Celým přístupem prochází jeden princip: všechno ověřuj, i to, co děláš sám.

‍

„Jako architekt jsem navrhoval vzory a pravidla. A pak jsem je sám porušil při pozdější úpravě."

‍

Ani code review od vývojářů nestačí, věci proklouznou. Proto stavíme projekty s automatickými kontrolami: pravidla pro architekturu a packaging, quality gates měřící pokrytí a duplicity, kód, který sám upozorní, když někdo použije zakázanou nebo duplicitní knihovnu.

‍

Vývoj s pomocí AI bez ztráty kontroly nad kódem

Stejný princip se dnes rozšiřuje na nového účastníka v codebase. AI agenti generují kód tempem, které lidské týmy nemohou dohnat. Správné využití šetří čas, omezuje repetitivní práci a uvolňuje zkušeným vývojářům prostor pro rozhodnutí, na kterých skutečně záleží. Bez pravidel se ale rychle odchýlí od kvality, na které bankovní projekt závisí.

‍

Interně rozlišujeme mezi vývojem s pomocí AI a tím, čemu se říká vibe coding. Vývoj s podporou AI znamená, že zkušení vývojáři používají AI ke generování větších částí kódu, který pak revidují a dolaďují podle zavedených standardů. Vibe coding je spíš promptování směrem k funkčnímu prototypu. První přístup do produkčních bankovních aplikací patří. Druhý ne.

‍

Abychom udrželi výstup AI v souladu s tím, jak chceme kód psát, vznikl interní projekt Flow Guidelines for AI. Přináší naše vývojové standardy přímo do AI nástrojů, takže generovaný kód dodržuje stejná pravidla, která by ručně aplikoval senior vývojář. Princip z architektury platí i tady: všechno ověřuj, i to, co děláš sám, a AI ze všeho nejvíc. Celý přístup jsme popsali v samostatném článku.

Bezpečnost stojí na stejném základě

Architektura a kontrola kvality určují, jak dobře produkt škáluje. Zároveň určují, jak velkou útočnou plochu někdo dostane k dispozici. Obě roviny jsou neoddělitelné. Proto dodáváme bankovní aplikace společně s Wultrou, kteří mají na starosti bezpečnostní část: autentizaci, ochranu aplikace, bezpečný onboarding a vzory chránící uživatele při přihlášení, platbách a 3D Secure.

‍

Na našem společném webináři Boris Filčák z Wultry rozebral reálný investiční podvod, který je v současnosti aktivní v Evropě. Jeden telefonát, šedesát minut, tři úvěry sjednané na jméno oběti a €25 000 pryč. Žádný sofistikovaný útok, žádná hrubá síla. Dobře připravený útočník a řetězec rozhodnutí, která v každém kroku vypadala rozumně. Každému z nich bylo možné předejít dříve. Celý rozbor, včetně toho, kde leží jednotlivé body intervence a co změní PSD3 v oblasti odpovědnosti, najdete v záznamu webináře.

Co z toho plyne

Většina rozhodnutí, která určují, zda bankovní aplikace vydrží, se přijímá na začátku, lidmi, kteří u toho nebudou, až přijdou důsledky. Architekti odcházejí. Vývojáři mění firmy. Přicházejí nové týmy, AI agenti začínají přispívat kódem, bezpečnostní hrozby se vyvíjejí. Projekt běží dál.

‍

Co přežívá, je disciplína zabudovaná do základů. Dokumentace, která vysvětluje proč. Architektura, která vynucuje vlastní pravidla. Standardy, které drží AI na stejné úrovni jako seniora. Bezpečnostní vzory, které fungují i tehdy, když uživatelé udělají chybu.

‍

Zvenku nic z toho není vidět. Neprojeví se v hodnoceních v App Storu ani v roadmapách funkčností. Projeví se v tom, co se nestane. Ve vývoji, který se za tři roky nezpomalí. V přepracování, které se nehromadí. V bezpečnostním incidentu, který se nestane titulkem.

‍

Vidíme to z obou stran. Klienti, kteří si před lety vzali vývoj zpět interně, se vracejí, když potřebují pohled zvenku: architecture review, druhý názor na zásadní rozhodnutí, ověření směru, který zvažují. Rozhovor zpravidla začíná u kódu, který jsme psali my, stále běží a stále se na něm shipuje. To je nejsilnější signál, který dostáváme, že základy vydržely.

‍

To je to, co stavíme. Aplikace, které pět let po spuštění stále běží, stále se zlepšují a stále jim někdo důvěřuje. A týmy, které dokážou vysvětlit, proč kód vypadá tak, jak vypadá.