Gaining Speed Yet Losing Altitude - S1:A2

S1:A2 - 'Low-code' staat niet gelijk aan 'no-code'

Voor veel bedrijven is het cruciaal om continu nieuwe releases live te zetten. Dat vraagt om supersnel software ontwikkelen, die per direct de klantvraag adresseert. Low-code platformen maken dit voor steeds meer organisaties en toepassingen werkelijkheid. Maar, de snelheid van low-code ontwikkeling vraagt, nóg meer dan ‘vroeger’, wel om adequate QA- en testoplossingen. Hoe sneller je figuurlijke low-code vliegtuig vliegt, hoe belangrijker het is de juiste maatregelen te nemen om geen hoogte te verliezen.

In de serie Gaining Speed Yet Losing Altitude bespreken we steeds een low-code kwaliteitsuitdaging en de maatregelen die je kunt nemen.

Pas op met regular-code in low-code apps

In mijn vorige blog (S1:A1 Snelheid vs Kwaliteit - Zo haal je het maximale uit je low-code platform) vertelde ik dat veel organisaties worstelen met de balans tussen snelheid en kwaliteit. Low-code is een van de manieren om deze snelheid te realiseren. Je maakt dan dus geen gebruik meer van ‘regular-code’ technologieën zoals JAVA of C#. Low-code platforms als Mendix en OutSystems beloven een 7 tot 10 keer hogere productiviteit ten opzichte van regular code.

Dit klinkt alsof low-code de juiste keus is. Maar is dat wel zo? Als het alleen om snelheid gaat wellicht wel. Maar volgens mij moet je verder kijken dan alleen snelheid. Biedt low-code jouw ontwikkelteam bijvoorbeeld alle opties en mogelijkheden die je (en jouw gebruiker/klant) nodig hebt?

De uitdaging

In sommige situaties is het antwoord op deze vraag nog steeds ‘nee’. Low-code platforms hebben veel 'out of the box' bouwstenen en functionaliteit die ontwikkelaars direct kunnen gebruiken. Maar soms heb je aan alleen low-code niet genoeg.

Ontwikkelaars zijn over het algemeen behoorlijk creatief. En als low-code de klus niet klaart, vallen ze terug op wat ze waarschijnlijk al weten: regular code. Sterker nog, zowel Mendix als OutSystems bieden ontwikkelaars mogelijkheden om regular code zoals JAVA, JavaScript en C# op te nemen in hun low-code oplossingen. Met andere woorden, ‘low-code’ staat niet gelijk aan ‘no-code’.

Omnext heeft inmiddels honderden geautomatiseerde scans uitgevoerd. En we zien dat meer dan 50% daarvan regular code-elementen bevat.

Hebben we het probleem hiermee opgelost?

Ja en nee. Probeer altijd om de regular code in je low-code apps tot een minimum te beperken. Als je per saldo meer regular code dan low-code hebt, dan is het misschien verstandig om nog eens te kijken of low-code de juiste keuze is. Bij verstandig en zorgvuldig gebruik kan regular code in low-code-apps ontwikkelaars in staat stellen functionaliteit te bouwen die anders niet mogelijk is. In die zin beantwoordt dit aan de oorspronkelijke uitdaging.

Maar, het brengt ook een aantal potentiële nieuwe risico's met zich mee:

1. Hoe weet je of de toegevoegde code onderhoudbaar is? Als je niet echt inzicht hebt in de (hoeveelheid) code die handmatig is toegevoegd, hoe weet je dan of de kwaliteit goed is?
2. Hoe weet je of deze toegevoegde regular code veilig is? Het maakt immers geen deel uit van de ingebouwde beveiligingsmaatregelen van het low-code platform.

De oplossing

De vraag is dus niet óf je regular code moet gebruiken in je low-code apps. Maar hoe je ervoor zorgt dat deze handmatig toegevoegde regular code aan dezelfde kwaliteitsnormen voldoet als de rest van de (low-code) app.

In mijn vorige blog noemde ik al de drie elementen die nodig zijn om de softwarekwaliteit te waarborgen: 1) Kwaliteitsbewustzijn, 2) Kwaliteitsinvestering en 3) Kwaliteitsautomatisering. Dezelfde elementen gelden hier ook, maar met een iets andere focus. Teams die met low-code platforms werken, moeten bijvoorbeeld weten dat het gebruik van regular code niet verboden is, maar dat ze het wel verstandig en zorgvuldig moeten gebruiken. En als ze dan regular code toevoegen, dat er dan een code review is en getest wordt.

Vooral dat laatste wordt vaak over het hoofd gezien. En in de meeste gevallen ligt dat niet eens aan de teams zelf. Het is vaak de geautomatiseerde low-code reviewtool zélf die geen rekening houdt met regular code in low-code-analyses. Deze tools zijn vaak alleen gericht op het evalueren van het low-code-model. De meeste tools kunnen niet eens regular code analyseren, laat staan dat ze worden ingebed in een low-code app.

Hoe Omnext het verschil kan maken

Een van de tools die regular code in low-code apps niet negeert, is het Omnext Fit Test-platform. Omnext is al meer dan 15 jaar gespecialiseerd in softwareanalyse. In deze 15 jaar is een platform gebouwd dat niet alleen low-code platforms zoals Mendix en OutSystems ondersteunt, maar ook regular code-technologieën zoals JAVA, JavaScript en C#. Dit maakt Omnext een van de meest geschikte geautomatiseerde code-review tools die in staat is om in één keer analyses uit te voeren op applicaties die meerdere technologieën bevatten.

Tijdens de geautomatiseerde analyse toetst het platform jouw low-code applicatie tegen low-code specifieke best practices. Daarnaast evalueert het ook eventuele toegevoegde regular code zoals JAVA, tegen JAVA specifieke best practices en elementen van de ISO-25010 richtlijn voor softwarekwaliteit zoals Onderhoudbaarheid, Betrouwbaarheid, Prestaties en Beveiliging.

Met andere woorden, het evalueert jouw volledige applicatie technologie stack. Mijn advies: beperk het gebruik van regular code in low-code apps altijd tot een minimum. En gebruik een tool zoals Omnext. Dan hebben jouw ontwikkelaars in ieder geval de zekerheid dat hun regular code niet over het hoofd wordt gezien en dat het voldoet aan dezelfde kwaliteitsnormen.

Wil je meer weten? Neem contact op met Omnext via contact@omnext.com

Bezoek www.omnext.com voor meer informatie

Omnext is een Valori solution

Over de auteur

Bryan de Vries is Chief Commercial Officer bij Omnext. Hij is verantwoordelijk voor business en product development en partnerships. Bryan heeft een sterke focus op de low-code oplossingen van Omnext en adviseert organisaties over software kwaliteitsvraagstukken.