Det är en högst relevant fråga. Moderna och bra metoder för att driva programutvecklingsprojekt har ju funnits väldigt länge. Vad är det då som gör att en ”dum” robot kan göra jobbet bättre?
Jo, det finns ett inbyggt problem med programmering, som låter sig lösas på ett bättre sätt genom att använda en robot som skriver programkod. Nu blir inte alla programmerare arbetslösa på grund av detta. Mjukvarurobotar måste också programmeras, men den totala programmeringsinsatsen minskar.
Här är en stegvis förklaring till varför det fungerar:
Det hela börjar oftast med en idé
Vad en programvara ska innehålla och vilka problem den ska lösa uttrycks vanligtvis genom att det finns en idé om vad innehållet ska vara. Den idén ska sedan översättas till ett program som då förhoppningsvis uppfyller intentionen med idén.
Från idé till körbart program
Det kan verka självklart, men till sist är det ju inte själva idén som levereras till kund, utan det färdiga programmet.
I praktiken innebär det att ett eller flera filer med källkod behöver skrivas. De ska sedan kompileras och byggas ihop med resten av applikationen till ett körbart program.
Hur bra programmets sedan stämmer överens med idén beror bland annat på följande delar:
- Hur väl idén är uttryckt i termer av dess affärsmässiga innehåll.
- Hur bra den informationen kan transformeras till ett program.
- Kvalitén på den kod som programmet sedan består av.
Källkodens innehåll måste uppfylla dubbla syften
Själva kärnan i problematiken är att källkoden måste innehålla två saker samtidigt. Källkoden måste helt enkelt bestå av en blandning av innehåll från två sidor, exemplifierat med röda och blå rader i bilden nedan.
Koden behöver innehålla,
- innehålla definitioner och algoritmer som uppfyller den idé som ligger till grund för programmet
- de specifika regler som gäller för den miljö som applikationen ska köras i. Det kan gälla operativsystem, hjälpbibliotek, standarder och annat, som samtliga normalt förändrar sig över tid. Nya versioner kommer och går, gränssnittet mot användarna behöver moderniseras, med mera.
Just den här blandningen av dubbla aspekter i samma textmassa är det som egentligen gör att ett program kan vara svårt att underhålla, krävs utförliga tester, och kostsamma att utveckla vidare.
Separera idén från implementationen
Första steget för att lösa upp den här problematiken är att separera den kod som kommer av idén från den kod som kommer av ett visst val av implementation.
Den kod som kommer från idén samlas då i en egen fil, en specifikation. Den fungerar som en kortfattad idébeskrivning. Skillnaden är att den enbart innehåller text som handlar om idén, inte något om implementationen.
Låt en robot ta hand om implementationen
Kvar blir då ”bara” ett skelett med principer och mallar för de regler som gäller när en korrekt implementation ska skapas. De reglerna är förutsägbara och kan tas över av en robot.
Nu blir de två sidorna separerade. Idén manifesteras i en formell specifikation som kan läsas en en mjukvarurobot. Den i sin tur är programmerad att skapa kod som passar in i den aktuella miljö där programmet ska köras.
Roboten fungerar nu som en brygga mellan de två världarna. När förutsättningarna ändras på någon av sidorna är det bara att köra roboten igen och bygga om applikationen.
Applikationen blir framtidssäkrad
Genom att roboten sköter all implementationsspecifik kodning, så blir det mycket enklare att anpassa till nyare versioner av operativsystem, hjälpbibliotek. Det är också helt möjligt att göra stora strukturella förändringar.
Samtidigt är det enkelt att bygga ut och ändra den affärsmässiga idé som programmet ska utföra. Detta genom att helt enkelt ändra specifikationen och köra om roboten för att få ny kod.
Fördelar och nackdelar
Genom att använda en robot så separeras det affärsmässiga innehållet från detaljer i implementationen.. Det gör att båda kan utvecklas oberoende av varandra.
Kostnaden för att prova och att göra prototyper på ny funktionalitet minskar också drastiskt eftersom det går snabbare prova sig fram i stället för att behöva veta alla detaljer från början.
Att kunna leverera program och appar på nya plattformar eller versioner blir enklare i och med att bara roboten behöver anpassas.
Introduktionen av ett nytt sätt att skriva specifikationer kräver en del utbildning, eftersom de måste vara så stringenta i syntax att en robot kan läsa dem.
Samtidigt är det också en fördel att ha stringenta specifikationer. De kan därmed lagras i ett repository tillsammans med den resulterande källkoden. På det viset får man full spårbarhet på alla ändringar och den effekt de fått på applikationen.
Låter det intressant? Kontakta Oss för att få veta mer!