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. Cíl zůstává stejný: 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 stíhat. Správné využití šetří čas, omezuje repetitivní práci a uvolňuje zkušeným vývojářům prostor pro strategická rozhodnutí. Bez pravidel se ale agenti rychle odchýlí od kvality, na které bankovní projekt stojí.

‍

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 se 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 partnerem Wultra, který má jako specialista 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ý byl v současnosti zaznamenán v Evropě. Jeden telefonát, šedesát minut, tři úvěry sjednané na jméno oběti a ztráta €25 000. Žá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. Celý případ, včetně toho, 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 dělá na začátku, lidmi, kteří u toho nebudou, až se projeví 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í. A projekt musí běžet dál.

‍

Co zůstá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 je senior vývojář.
• Bezpečnostní vzory, které fungují i tehdy, když uživatelé udělají chybu.

Zvenku nic z toho není vidět. Neprojeví se to nutně v hodnoceních v App Storu ani v roadmapách funkcionalit. Projeví se v tom, co se nestane. Ve vývoji, který se za tři roky nezpomalí. V opravách, které se nehromadí. V bezpečnostním problému, který se nestane titulkem novin.

‍

Vidíme to z obou stran. Klienti, kteří si vývoj internalizovali, se vracejí, když potřebují pohled zvenku: revizi architektury, druhý názor na zásadní rozhodnutí, ověření směru, který zvažují. Rozhovor často 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, že naše základy vydržely.

‍

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