Rostoucí zájem firem o digitální transformaci vede ke vzniku nástrojů, které staví na jednoduchosti, automatizaci, ale také dostupnosti. Do oblasti vývoje softwaru tak začala pronikat například umělá inteligence, low-code a no-code platformy nebo tzv. multiplatformní frameworky pro sjednocení frontendů aplikací, typicky jeden kód pro web a mobilní aplikaci. Důvod? Jednoduchý. Všechny tyto nástroje a technologie mohou pomoci vývoj softwaru urychlit. Ale taky nemusejí.

Technologie pomáhají, když víte jak

Buzzword AI v posledním roce dynamicky proniká do různých profesí a trochu přitom odhaluje, jakým způsobem daná profese vlastně funguje. Někde dokáže nahradit celou službu, jinde ji lze používat pro usnadnění práce jen v jistých fázích nějakého procesu či úkolu. Vždycky však potřebuje vedení člověka, který čerpá ze svých pracovních zkušeností a dovedností.

Dosavadní práce s AI při vývoji softwaru rovněž ukazuje, že člověk je zatím stále tím, kdo táhne věci kupředu. Vůbec neplatí, že by z méně zkušeného člověka AI udělala seniora a ze seniora by udělala nadčlověka. Umělá inteligence umí pomoci s úkony, ale seniorní vývojář by měl být tím, kdo určuje, co má dělat a jakým způsobem. Je to stejné, jako když si firma zadá vývoj a za product ownera dosadí někoho, kdo technologii, procesu vývoje ani byznysovému cíli zamýšleného produktu vůbec nerozumí. Jako vývojářské studio už ze zkušeností víme, jak v takových situacích edukovat klienta a vše nastavit tak, aby pro něj i pro nás měla spolupráce smysl. Jenže pokud obdrží chybné zadání a podklady AI, bude přece i její výstup problematický – zkrátka jako možný přístup některých vývojářů, kteří nekvalitní výsledek komentují slovy „vždyť jste to tak chtěli“. A tak AI zatím nemůžeme vnímat jako formu vyšší inteligence, která udělá všechno dokonale za nás. Přistupovat s touhle myšlenkou k tvorbě nové aplikace se rozhodně nevyplácí.

Totéž platí pro low-code a no-code. Tyto nástroje mohou být při dobré IT governance užitečné třeba na prototypování již vytvořeného designu nějaké aplikace. Při vývoji aplikací se totiž dost často řeší, že testovat design jejich statické formě nestačí. Vyžaduje to mnohdy komplikovanou synchronizaci práce grafiků a vývojářů, jejichž výsledek slouží často opravdu jen pro účely uživatelského testování. Nicméně s low-codem a no-codem je možné vytvořit rychle velmi funkční řešení, které se může testovat „naživo“ a uživatel s ním zároveň může interagovat na fyzickém zařízení. Což dá grafikům daleko lepší představu o funkčnosti jejich řešení než statický prototyp např. ve Figmě.

Hodně se také mluví o multiplatformním frameworku, jako je například Flutter neboli open-source vývojový nástroj na vývoj softwaru, který vytvořila společnost Google. V ELEVUPu Flutter využíváme téměř od jeho vzniku v roce 2017 a máme v něm napsaných několik aplikací, které využívají statisíce lidí. Flutter dokáže signifikantně ušetřit náklady, to ale není pro úspěch projektů vždy to hlavní.

Multiplatformní technologie u zákazníků vzbuzují otázku, jestli nejde napsat ve Flutteru např. i celý web s využitím jednoho kódu pro Android, iOS i web. Jasně, to jde. Ale je otázka, do jaké míry to dává smysl? Je framework připravený na takový rozvoj? Protože i když se Flutter zdá pro méně znalé jako logická volba, má taky spoustu omezení, která zjistíte až jeho intenzivním a dlouhodobým používáním. Taky je otázka, jestli je takový postup vhodný s ohledem na povahu produktu a samotný byznys, což je něco, co by měl mít v prvé řadě rozmyšlené klient, a vývojářské studio mu být současně validátorem. Jenže to v praxi často dopadá tak, že klient má úplně zkreslené představy a vývojáři na nějaký byznysový a strategický přesah vytvářeného produktu úplně kašlou.

AI jako řešení na lidské ego?

Vývoj nového softwaru se neobejde bez testování s cílem odhalit chyby v programech. S tím souvisí trend posledních dnů v použití funkce tzv. code coverage s pomocí AI. Jde o metriku, která měří, kolik kódu se během testů skutečně pokryje. Nižší procento pokrytí totiž může znamenat, že existují části kódu, které otestované nejsou, a proto mohou obsahovat chyby. Zároveň ale vysoké procento code coverage ani zdaleka neznamená, že je test dokonalý, nebo vůbec správně postavený. Proto je dobré kombinovat code coverage s dalšími metodami pro ověření kódu a nebrat to jako jediný ukazatel kvality testů.

Chlubit se vysokou code coverage percentage mi ve většině případů přijde jako egoistické klamání zákazníka, a proto tuhle hodnotu obvykle nevnímáme jako dogmatickou ani moc vypovídající. Proč? Dává totiž smysl jen ve chvíli, kdy test napíše třeba někdo jiný než např. vývojář dané funkce, zároveň když je test napsaný ještě před tím, než se do samotného vývoje vůbec pustíte. Problém je však v tom, že takový přístup je obvykle extrémně zdlouhavý a pro klienta by se zásadně prodražil. Obvykle to pak na trhu dopadá tak, že si jeden vývojář napíše funkce či metody dle svého nejlepšího vědomí a svědomí a následně si na něj sám udělá – nečekaně vysoce úspěšný – test, což je asi stejně smysluplné jako si oznámkovat vlastní domácí úkol, aniž víte, jestli ho vůbec máte správně.

Řešením celého problému by tak mohla být právě AI. Ať už pro doplnění komentářů k vlastním metodám, nebo naopak k získání rychlého názoru na cizí metody. Díky tomu, že je umělá inteligence rychle okomentuje, můžete zakrátko získat vhled a zjistit, co váš kód dělá. Může vám tak pomoci se zpětnou vazbou. I zde je ale otázka, nakolik je to užitečné při stávajícím nastavení trhu. U řady zadavatelů totiž stále ještě přežívá přesvědčení, že je třeba mít aplikaci před vypuštěním do světa co nejdokonalejší, vymazlenou a bez chyb. To ale vede ke zbytečným průtahům, zatímco by produkt už mohl být dávno venku, a navíc reálnou validaci své práce stejně získáte až teprve tehdy, kdy ji začnou používat zákazníci. Nějaký ten bug se vždycky objeví, zejména pokud si neefektivně necháváte dělat vývoj jednoho projektu více firmami či odděleními ve větších firmách nebo v něm využíváte příliš různých technologií a nástrojů.

Proto je lepší vydávat spíše minimum viable product (MVP, minimální životaschopný produkt) co nejdříve i za cenu toho, že ještě není vše perfektní. Protože od okamžiku spuštění můžete sbírat zpětnou vazbu od reálných uživatelů a iterovat aplikaci za chodu. Minimalizujete tak nutnost cokoli dodatečně předělávat, protože jste třeba zjistili, že vaše původní odhady byly špatné a zákazníky vaše dlouho plánovaná a do detailu laděná aplikace v reálu vlastně vůbec nebere. MPV vám naopak mnohem rychleji začne přinášet uživatele a tím si na sebe i pravděpodobně dříve vydělá, a vy pak tyto finance můžete zpětně investovat do těch oblastí, které se pro zákazníky i váš byznys potvrdily jako smysluplné. Navíc pak můžete na pravidelné bázi vydávat vylepšení, což při dobré komunikaci na koncové uživatele působí líp. Protože vidí, že se v aplikaci stále něco děje a že vám na jejím úspěchu a dlouhé životnosti opravdu záleží.

Co je tedy metrika?

Na konec stojí zmínit fakt, že jako konzumenti technologií, možností přístupu k softwaru, různých agilních metodik, ať už škálovaných, či ne, zapomínáme z 99 % na fundamentální aspekt vývoje softwaru a vlastně veškeré tržní činnosti dnešní doby. Tím jsou příjmy. A nemám na mysli nutně příjmy finanční, ačkoli převažují, ale můžeme se bavit o počtu validních leadů na potenciální klienty, ze kterých příjmy vytěžím. Můžeme se bavit o prudkém nárůstu uživatelů a jejich retenci, jejich stráveném času na webu, který konvertuje např. ziskem z reklam či dává větší páku pro inzerenty atp. Proto je občas dobré na chvilku odstoupit, podívat se na věci s nadhledem a nenechat se strhnout vším, co se na nás valí, jenom proto, že to má řádný hype. Proto děláme, co děláme – a co je a co není hype, je náš denní chleba už nějaký ten pátek.

Daniel Jay Lett Autor je spoluzakladatelem a CEO vývojářského studia elevup.