Teknik och samhälle
Datavetenskap och medieteknik
Examensarbete
15 högskolepoäng, grundnivå
Kartläggning av önskvärda egenskaper i arkitekturer samt
ramverk för separation av användargränssnitt från logik
En analys av arkitekturer och ramverk i mjukvaruprojekt.
Survey for desired properties in architectures and frameworks for
separation of user interface from logic
An analysis of architectures and frameworks in software engineering projects.
Alper Kilic
Johan Åkesson
Examen: Kandidatexamen 180 hp Handledare: Farid Naisan Huvudområde: Datavetenskap Examinator: Magnus Johnsson Program: Systemutvecklare
Abstract
Choosing an architecture or a framework for a system can be tricky at times especially for beginners. The wrong choice can not only affect the projects success rate negatively but can also be a bad business decision. When developing a new framework or
architecture the developer should know what properties that framework or
architecture should support. This study have therefore chosen to present different architectures and frameworks and analyze their properties.’
By using semi-structured interviews and internet surveys to ask developers about these properties we have presented why and which properties are most important and what developers are looking for in an architecture or a framework. Thereby the
purpose of this study is to either offer the reader help with choosing the right architecture or acknowledge the properties when developing a new one. Similar studies seem to focus on undefined adjectives whereas this study will explain and discuss these properties in detail. The result of the study is too weak to be able to represent all developers but could indicate that ease of use, documentation, a community and a unidirectional data flow are properties that are preferred. The respondents are however torn and seem to have different opinions on whether or not properties such as pre-generated code, modularity and testability should be preferred over other properties. The goal is to hopefully inspire other studies to examine these properties further or to help developers understand frameworks and architectures and their properties better, thereby making it easier for them to choose one or to develop one.
Sökord
Användbarhet, enkät, dokumentation, dataflöde, inlärning, för-genererad kod, modularitet, testbarhet, designprinciper, arkitektur, ramverk, enkelriktat dataflöde, gemenskap,
Ordlista
Binder/Data binding - Teknik som binder data, exempelvis att ett element är bundet till ett annat element, d.v.s när en ändring sker i det ena elementet vet det andra elementet om detta.
Tillstånd (state) - Ett program/systems nuvarande värden/innehåll.
Dataflöde - Den riktning data skickas transporteras i. Kan vara enkelriktad eller dubbelriktad.
Coupling - Mått av hur nära och hur beroende två moduler är av varandra.
Community - Grupp av människor med ett gemensamt intresse, detta innebär ofta att intresset diskuteras. Exempelvis ramverk inom utveckling.
Oföränderlig data - Data som inte går att redigera utan måste ersättas komplett.
Decoupled - Decoupled innebär att moduler inte alls är beroende av varandra
Loosely coupled - Loose coupling innebär att moduler inte är starkt beroende av varandra.
Ramverk - Programvaru-miljö som vanligen innehåller ett kodbibliotek vilket
tillhandahåller allmän funktionalitet för att underlätta vid utveckling av system. Ett ramverk kan även vara utformat på ett specifikt vis för att upprätthålla regler från exempelvis en arkitektur.
Arkitektur - Specifikation av de komponenter som ett system består av samt kommunikationen mellan dessa komponenter.
Abstract 1 1.0 Inledning 6 1.0.1 Motivering 8 1.1 Syfte 8 1.1.1 Problemställning 8 1.2 Avgränsning 9 1.3 Forskningsfrågor 9 1.4 Teori 9 1.4.1 Model-View-Controller 10 1.4.2 Model-View-Viewmodel 12 1.4.3 Flux 13 1.4.4 Ruby on rails 14 1.4.5 Redux 15 2.0 Metod 16 2.1 Metod-diskussion 17 2.1.2 Förkastade metoder 17 2.2 Datainsamling 18 2.2.1 Litteraturstudie 20 2.2.2 Sökprocess 20 2.2.3 Semistrukturerade intervjuer 20 2.2.4 Enkät 21 2.3 Urval 21 3.0 Resultat 22
3.1 Sammanställningar och fynd ur litteraturstudien 22
3.2.0 Åldersfördelning 24
3.2.2 Demografi 25
3.2.3 Erfarenhet 25
3.2.4 Olika arkitekturer 25
3.2.5 Olika ramverk 26
3.2.6 Viktiga egenskaper i en arkitektur 26
3.2.7 Viktiga egenskaper i ett ramverk 27
3.2.8 MVC 27
3.2.9 MVVM 28
3.2.10 Flux 29
3.2.11 Ruby on Rails 30
3.3 Intervjuer 32
3.3.2 Kännedom arkitektur 32
3.3.3 Kännedom ramverk 32
3.3.4 Valet av arkitektur och ramverk 32
3.3.5 Modularitet och testbarhet 33
3.3.6 Dataflöde 33
3.3.7 Inlärningskurva 34
3.3.8 Vad gör något populärt? 35
3.3.9 För-genererad kod 35
3.3.10 Oföränderlig data 36
3.3.11 Versionshantering 36
3.3.12 Dokumentation och community 36
3.3.13 Kategoriserad data 37
4.0 Analys och diskussion 38
4.1 Deltagarnas kännedom av arkitekturer och ramverk 38
4.2 Modularitet och testbarhet 38
4.3 Dataflöde 39
4.4 Marknadsföring och tillgänglighet 39
4.5 Community 40
4.6 Dokumentation och inlärning 40
4.7 Versionshantering och kategoriserad data 41
4.8 För-genererad kod och möjlighet till anpassning 42
6.0 Slutsats 43 6.1 Rekommendationer 44 7.0 Referenser 45 Bilagor 49
1.0 Inledning
Mjukvaruprojekt kräver ofta en design eller arkitektur som skall beslutas om innan utvecklingen påbörjas. Valet av design kan även ses som ett affärsbeslut då ett välgrundat val av arkitektur kan bidra till ett lyckat projekt[5]. Rätt designval kan resultera i effektivare hantering av en organisations resurser, exempelvis kan en arkitektur göra ett system modulärt vilket tillåter fler utvecklare att arbeta på ett projekt samtidigt. Modulära system isolerar problem och gör varje moduls ändamål tydligt. Utvecklare behöver således endast veta vad den särskilda modulens ändamål är och behöver inte förstå helheten av systemet. Vilket i sin tur genererar mer effektivt arbete då utvecklaren inte behöver spendera tid på att sätta sig in i andra moduler eller tekniker.
Det finns ett brett utbud av ramverk och arkitekturer som samtliga antingen beskriver eller hjälper utvecklaren implementera en särskild design. Designvalet bör grundas i de tekniska, sociala samt affärsmässiga förutsättningar som organisationen besitter. Boken “Software architecture in practice[31]” beskriver hur dessa förutsättningar influeras av tre olika faktorer:
Tekniska - Den tekniska miljö som utvecklaren befinner sig i kommer påverka valet av arkitektur. Detta kan påverkas av olika trender och standardiserade arbetssätt.
Affärsmässiga - Organisationen i fråga kan ha investerat resurser i befintliga tekniker och saknar resurser för att byta arkitektur eller ramverk. Det finns redan en långsiktig investering i en viss typ av teknik. Organisationens struktur kan påverka projektets arkitektur, om organisationen behöver nyttja underleverantörer kan det vara
fördelaktigt att använda en arkitektur som isolerar moduler i systemet så att de olika organisationerna kan arbeta fristående, utan att påverka varandra.
Sociala - Utvecklare utgår främst från de arkitekturer och arbetssätt som tidigare gett ett positivt utfall. På samma sätt undviks tekniker som resulterat i ett negativt utfall. Valet kan även grundas i utbildning och nyfikenhet.
Att välja fel metod kan försvåra utvecklingsprocessen och leda till ett ineffektivt användande av organisationens resurser. I värsta fall kan denna felbedömning resultera i ett misslyckat projekt[5]. Rätt ramverk eller arkitektur kan förenkla utvecklares arbete då de kan erbjuda färdig kod eller en färdig grund till en applikation. Fel val av ramverk eller arkitektur kan leda till ökade kostnader och minska företaget eller produktens konkurrenskraft.
I boken “Software architecture in practice[31]” dras en anekdot till det svenska
krigsfartyget Vasa som byggdes utan att betrakta den arkitektur som fartyget krävde. Detta resulterade i att fartyget välte omkull strax utanför hamnen och kostade livet på flera i besättningen. Även om detta är något av ett extremt fall kan samma argument
Studiegruppen samarbetade med ett utvecklingsföretag baserat i Lund. Samarbetet genererade data i form av intervjuer av anställda inom företaget. De anställda besatt olika roller och arbetade på olika avdelningar. Fortsättningsvis då studien nämner “Företaget” refererar skribenterna till utvecklingsföretaget i Lund.
I samråd med Företaget valde studien att undersöka följande ramverk och arkitekturer:
Ruby on rails[1].
Ruby on rails hjälper utvecklare att bygga applikationer snabbare genom att erbjuda en färdig grund till applikationer som utvecklare kan vidareutveckla.
Redux[2].
Redux är ett ramverk som hjälper utvecklare att bygga applikationer vars beteende är oberoende oavsett miljö. Redux hjälper utvecklare att centralisera applikationens tillstånd samt ökar applikationens flexibilitet. Redux används främst tillsammans med ReactJS till utveckling av webbapplikationer.
Flux[3].
Flux är en arkitektur som används vid utveckling av webbapplikationer på
klientsidan. Flux används främst tillsammans med ReactJS och kompletterar dess komponenter genom att använda ett enkelriktat informationsflöde.
MVC[10][11].
Model-View-Controller är en arkitektur som delar in en applikation i tre olika lager med avsikt att separera användargränssnitt från logik. Separationen av
användargränssnittet tillåter utvecklare att byta ut samt uppdatera den grafiska delen av applikationen.
MVVM[13].
Model-View-ViewModel är en arkitektur som likt MVC separerar applikation i tre lager. Till skillnad från MVC har MVVM dock ingen controller utan ett lager (ViewModel) som ligger mellan view och model. Detta lager använder sig utav en binder och
automatiserar kommunikationen mellan view och model.
Studie granskade utvalda arkitekturer och ramverk som används för att separera användargränssnitt från logik.Forskningsfrågorna besvarades genom en enkät, semistrukturerade intervjuer med mjukvaruutvecklare samt en litteraturstudie.
1.0.1 Motivering
Den gemensamma nämnaren i de arkitekturer och ramverk som valdes ut av studien grundas i att samtliga är någon variation av MVC, eller vidareutveckling av MVC. MVC var bland de första arkitekturer med avsikt att separera programkod i moduler där varje modul har ett unikt ansvarsområd[25].
Valet av Flux, Redux och Ruby on Rails grundas i att samtliga tekniker är moderna och används i industrin. Företaget och dessa anställda använder dessa tekniker vilket gjorde att studien hade goda möjligheter att få svar på komplicerade frågor kring teknikerna.Valet av Redux och Flux motiveras även genom att de båda grundas i en komponentbaserad utvecklingsmiljö, huvudsakligen React. React har blivit ett
populärt verktyg för front-end utveckling inom webbutveckling och ökar ständigt i antal användare[26].
1.1 Syfte
Studien ämnade att analysera särskilda perspektiv inom de olika tekniker som nämnts. Dessa perspektiv innefattar: användarvänlighet, dataflöde, dokumentation, gemenskap/popularitet, inlärningskurva, för-genererad kod, modularitet, testbarhet och hantering av data. Den kvalitativa data som studien genererat kommer sedan ligga som grund för de argument som tas upp i diskussionsavsnittet. Studiens ämnar således att skapa en förståelse för de olika perspektiven och hur dessa kan påverka en teknik eller en utvecklare.
Syftet är att identifiera hur de berörda områdena bör angripas och vilka faktorer som anses vara positiva eller negativa. De slutsatser som studien kommit fram till kan användas för att motivera valet av arkitektur eller ramverk samt hjälpa utveckling av kommande arkitekturer och ramverk.
Studien har utgått ifrån MVC, MVVM, Ruby on rails, Flux samt Redux.
1.1.1 Problemställning
Studien avser att underlätta för utvecklare inför val, utveckling eller vidareutveckling av arkitekturer eller ramverk. Vidare presenteras önskvärda egenskaper för att
underlätta framtida utveckling och kan således hjälpa till att identifiera de egenskaper som bör övervägas vid val, eller utveckling av en arkitektur eller ett ramverk.
Det kan vara svårt för nya utvecklare att förstå vilka aspekter som bör betraktas i ett projekts designval. Den empiriska data som studien genererat kan således agera som riktlinjer för framtida utveckling samt hjälpa användare att lättare förstå sitt behov för olika typer av projekt.
Arkitekturer och deras egenskaper beskrivs generellt med engelska ord med ändelsen “ity”. Ett exempel på detta kan vara: scalability, portability, availability etc. Dessa adjektiv grundas ofta i utvecklarens eller organisationens uppfattning av ordet och
besitter ingen direkt definition. Utvecklare som tar fram nya arkitekturer hittar ofta på nya ord eller använder gamla nyckelord för att beskriva en ny egenskap som kan tolkas olika beroende på vem som läser texten[27].
Studies kommer därför att återge en mer deskriptiv analys på de olika egenskaper inom arkitekturer och ramverk utan att beskriva dessa som enkla adjektiv.
1.2 Avgränsning
Urvalet av ramverk och arkitekturer grundades i de verktyg som anses moderna och används frekvent inom industrin. Vidare analyserades populära diskussionsforum och sociala nätverk för utvecklare. Studien valde således att avgränsa omfånget till MVC, MVVM, Flux, Redux samt Ruby on rails. Anledningen till att studien valde att
avgränsa omfånget till arkitekturer och ramverk som är baserade på MVC var för att MVC dels är en av de mest välkända arkitekturerna på marknaden samt är välanvänt inom den moderna IT-världen[36]. Utöver MVC, MVVM och Ruby on rails valde
studien arkitekturen Flux och ramverket Redux, detta till största del för att företaget i fråga använde dessa tekniker.
1.3 Forskningsfrågor
● Hur anser utvecklare att arkitekturerna MVC, MVVM och Flux, samt ramverken Ruby on Rails och Redux bör överväga de aspekter studien granskar*?
● Utifrån de aspekter* som studien granskar, vad anser utvecklare vara positivt i de sätt som MVC, MVVM och Flux, samt ramverken Ruby on Rails och Redux behandlar sagd aspekt?
● Utifrån de aspekter* som studien granskar, vad anser utvecklare vara negativt i de sätt som MVC, MVVM och Flux, samt ramverken Ruby on Rails och Redux behandlar sagd aspekt?
*De aspekter som granskas innefattar: användarvänlighet, dataflöde, dokumentation,
gemenskap/popularitet, inlärningskurva, för-genererad kod, modularitet, testbarhet och hantering av data
1.4 Teori
Denna del av studien avser att informera läsaren om de olika koncept som behandlas i studien. Varje arkitektur och ramverk har brutits ner i sina huvudkomponenter och förklaras för att läsaren skall vara införstådd i de termer och begrepp som studien kommer att referera till. Studien fokuserar endast på arkitekturer och ramverk för systemutveckling vilket inte ska blandas ihop med arbetsmetoder likt
vattenfallsmetoden[19] och agila arbetssätt[19]. Huvudfokus kommer ligga på objektorienterad programmering men kommer även har inslag av funktionell programmering, främst inom webb.
1.4.1 Model-View-Controller
Model-View-Controller eller MVC är en känd arkitektur inom datavetenskapen. MVC hjälper utvecklare att bygga interaktiva system genom att underlätta separationen mellan användargränssnitt och logik. Model-View-Controller designades initialt för att bygga användargränssnitt inom applikationer som utvecklas med objektorienterade programspråk. MVC har blivit en arkitektur som många utvecklare använder och som är oberoende av programmeringsspråk[11]. Precis som namnet föreslår har
arkitekturen tre lager: model, view och controller.
Model
Modell-lagret representerar den domän som applikationen arbetar över, exempelvis tillstånd eller data för applikationen. Modellen är helt oberoende av
användargränssnittet därmed kan modeller användas för olika användargränssnitt utan ändringar.
View
Vyn är ansvarig för att visa informationen för användaren av programmet. Vyn kan ses som användargränssnittet till programmet. Användargränssnittet presenterar
informationen som ligger i modell-lagret.
Controller
Kontroll-lagret har hand om användarens interaktion med systemet och hanterar vad som ska visas. När en användare exempelvis trycker på en knapp via gränssnittet så agerar kontroll-lagret och gör den ändring som ska göras vid knapptrycket.
Fördelarna med att använda sig utav MVC kan exempelvis vara[10][11]:
● Applikationens utseende kan ändras med enkelhet utan att utvecklarna behöver ändra något i backend.
● Man kan använda sig utav flera olika gränssnitt och byta ut dessa utan svårigheter.
● Mindre koppling mellan komponenter. Nackdelar:
● Komplexiteten ökar. d.v.s att MVC kan vara onödigt för mindre applikationer där separation av användargränssnitt och logik inte är lika viktigt. ● Kan vara svårt att förstå sig på paradigmet samt kan vara svårt att
implementera utan erfarenhet.
Genom att separera användargränssnittet från logiken underlättar MVC för vidareutveckling och tillägg av fler användargränssnitt[10].
1.4.2 Model-View-Viewmodel
Model-View-Viewmodel[13] eller MVVM är en arkitektur som grundas i MVC. MVVM följer samma koncept för att separera logik från användargränssnitt och därmed ge möjligheten att använda samma logik för olika gränssnitt. Detta gör det enklare för utvecklare att underhålla, testa och utveckla en applikation. Den största skillnaden mellan MVVM och MVC är att istället för en controller så har MVVM en viewmodel som med hjälp av en binder automatiserar kommunikationen mellan view och model. Man kan beskriva ViewModel som ett tillstånd av en modell. Inom MVVM finns det tre separerade lager.
Model
Likt MVC innehåller modellen logik för applikationen och data som i sin tur visas för användaren genom ett användargränssnitt. Modell-lagret har i uppgift att paketera data och objekt som senare kan bli lästa av en vy.
View
Vyn är det som användaren av en applikation interagerar med. Likt MVC visar vy-lagret informationen för användaren genom ett användargränssnitt.
Viewmodel
Viewmodel-lagret är den mest avgörande skillnaden mellan MVVM och MVC. I
Viewmodel-lagret ligger den data som vyn ska visa paketerat. Viewmodel binder datan och ligger likt en brygga mellan vyn och modellen i applikationen. Viewmodels uppgift är således att “översätta” den logik och data som kommer från model-lagret till
view-lagret. Samt informationen som returneras från view-lagret till model-lagret genom data binding.
Figur 2: Dataflödet i en MVVM-applikation.
1.4.3 Flux
Flux[3] är en arkitektur framtagen av Facebook för att bygga webbapplikationer.
Arkitekturen är avsedd för React[20] som är ett bibliotek där komponenter används för att lagra grafiska modeller och tillstånd för varje enskild komponent. Flux togs fram för att förtydliga kod-basens funktioner och underlätta för nya utvecklare att
implementera nya funktioner. Huvudregeln i arkitekturen är att dataflödet skall vara enkelriktat och således enkelt att följa.
Nedan visas en bild på huvudkomponenterna i Flux och deras dataflöde:
Figur 4: Dataflödet i en Flux-applikation.
Dispatcher (avsändare)
Avsändaren är en centralenhet som lyssnar efter händelser, dessa händelser kan komma både från systemet men även via interaktioner från användare. Avsändaren består av ett register som specifikt berättar vad som ska ske i den delen av
arkitekturen som innehåller data och logik. Vilket i detta fall kallas modellen. Avsändaren innehåller ingen direkt logik utan är jämförbar med
Observer-mönstret[12]. Det är alltså avsändarens uppgift att delegera händelser till de områden som är intresserade och prenumererar på specifika händelser i systemet.
Store (modell)
Modellen innehåller applikationens tillstånd och de logiska operationer som skall utföras. Här lagras flera olika (React)-komponenter och deras tillstånd. Modellen prenumererar på olika händelser hos avsändaren och blir således, via avsändaren, meddelad när en viss händelse triggats i systemet. Modellen kan sedan manipulera tillstånd baserat på händelsen för att presentera en ny vy för användaren.
View (vy)
En komponent bestående av grafisk data och tillstånd för komponenten.
Action (händelse)
En specifik händelse som framkallats av systemet eller användaren. Händelsen
innehåller data beroende på vad för typ av händelse som inträffat samt vilket händelse som inträffat. Ett exempel kan vara händelsen “logga in” och den data som skickas med är själva inloggningsuppgifterna.
1.4.4 Ruby on rails
Ruby on rails[1], även kallat Rails är ett ramverk som används för att snabbt och effektivt kunna utveckla webbapplikationer. Rails-ramverket följer MVC’s
designprinciper och delar in applikationen i tre lager likt MVC. Därför är det viktigt att förstå sig på MVC-arkitekturen innan man använder Rails ramverk. Inom Rails finner man alla verktyg som behövs för att skapa applikationer som är i behov av en databas.
Figur 3: Dataflödet i en Ruby on Rails applikation.
Rails model layer
Modell-lagret inom Rails innehåller modeller, exempelvis card-objekt eller person object. Vidare kapslas all logik för applikationen in i detta lager. Inom Rails finns “database-backed model klasser” som gör att man kan visa data från databasen i form av objekt.
Rails Controller layer
Då Rails är ett ramverk för webbapplikationer är kontroll-lagret ansvarigt för inkommande HTTP requests och returnera lämpligt svar utifrån dessa. Vanligtvis betyder detta att HTML returneras men kontrollenheten kan även generera XML, JSON, PDF etc.
Rails view layer
I Rails vy-lager hittar man mallar som representerar den data som visas på webbapplikationen. Generellt kommer dessa mallar i form av HTML.
1.4.5 Redux
Redux[2] är ett ramverk framtaget för att implementera en underliggande arkitektur för webbapplikationer. Likt Flux fokuserar Redux på komponentbaserade lösningar
som exempelvis React. Dataflödet sker enkelriktat för att underlätta felsökning och förståelse av applikationen. Den data som lagras i modellen är omutbar och kan således inte ändras utan måste skapas på nytt vid modifiering.
Action (händelse)
Händelser i Redux är identiska med de händelser som används i Flux vilket studien behandlar ovan.
Reducer (förenkla)
En reducer är en funktion som alltid tar emot två parametrar - tillstånd och den händelse som inträffat. Tillståndet avser det globala tillståndet för applikationen som lagras i modellen. Det kan finnas flera olika reducers som alla ansvarar för en specifik del av modellen.
Store (modell)
Till skillnad mot Flux så innehåller Redux endast en modell, detta kan dock ändras för komplexa system, men utgångspunkten bör alltid vara en modell. Denna modell är oföränderlig och data kan således inte modifieras. För att modifiera data måste befintliga modellen ersättas med en ny modell, med nya tillstånd. Redux använder även en form av versionshantering av modellens olika tillstånd och man kan därför enkelt återgå till ett tidigare tillstånd vid exempelvis felsökning av applikationen.
Figur 5: Dataflödet i en Redux-applikation.
https://medium.com/fluttery/the-flutter-redux-problem-fa9d59ec97b8
2.0 Metod
Det finns ett flertal etablerade tillvägagångssätt för att utföra en forskningsstudie. Dessa tillvägagångssätt kallas forskningsmetoder. Valet av forskningsmetod bör grundas i målet av studien och de frågor som avses besvaras. Vetenskapliga metoder delas vanligen in i tre huvudsakliga kategorier, kvalitativa metoder, kvantitativa metoder och blandad metod. Den blandade metoden tar hjälp av både kvalitativa- og kvantitative inslamningsmetoder[35]. Då studien främst fokuserat på subjektiva åsikter valdes en huvudsakligen kvalitativ metod med inslag av kvantitativa metoder, en så kallad "mixed methods approach".
Då studien fokuserar på subjektiva uppfattningar i olika arkitekturer och ramverk, valdes därför semi-strukturerade intervjuer och digitala enkäter för att generera data som kan förklara och motivera subjektiva uppfattningar.
En survey utfördes för att kunna dra generella slutsatser kring forskningsfrågorna. Semistrukturerade intervjuer valdes som komplement till enkäten för att få fler detaljerade svar. En enkäts huvudsakliga uppgift är att kunna samla in större
mängder data från en utvald grupp. Genom att analysera den data kan slutsatser dras och generaliseras till en större mängd människor än den grupp som besvarat
enkäten[15]. Genom enkäter och intervjuer har data från en grupp utvecklare samlats in för att sedan kunna dra slutsatser kring vad utvecklare generellt anser om de utvalda arkitekturerna och ramverken samt deras egenskaper.
Surveys förknippas generellt med enkäter, dock så måste survey-metoden inte innebära enbart enkäter utan data kan även samlas in genom exempelvis intervjuer eller observationer[15].
Studien utförde en litteraturstudie för att kunna adressera forskningsfrågorna och koppla resultat från intervjuer och enkäter till befintlig forskning. En litteraturstudie innebär att söka relevant litteratur, granska dessa och sedan diskutera
sammanställningar från litteraturen. Därmed kan vissa argument förstärkas med hjälp av den data som hittats i tidigare litteratur inom samma område. Efter att litteraturen har sammanställts kommer fynd som är relevanta för studien och sammanställningar presenteras i resultatdelen.
2.1 Metod-diskussion
Digitala enkäter tillämpades för att generera bred data som sedan kan generaliseras. Syftet var att undersöka vilka arkitekturer och ramverk utvecklare känner till. Genom att skicka enkäten via Internet blir processen kostnadseffektiv, dessutom är det
enklare att nå ut till en större demografi av utvecklare[23]. Svaren som genererades av enkäten var otillräckliga för att vara representativt för alla utvecklare. Studien valde att använda den data som genererats, även om antalet svar inte är fullt representativt av alla utvecklare. Skribenterna kommer redovisa antalet svar i resultatdelen.
Motiveringen att använda den genererade datan till studien är för att förhoppningsvis skapa ett intresse som kan ge grund för ytterligare forskning inom området.
Utöver enkäten användes semistrukturerade intervjuer för att få djupare förståelse kring utvecklares subjektiva åsikter kring ramverk och arkitekturer.
Semistrukturerade intervjuer tillämpas då forskaren vill utforska personliga
upplevelser och personens känslor kring ett samtalsämne[22]. Då forskningsfrågorna bygger på individens subjektiva åsikter anser skribenterna att den data som genereras från semi-strukturerade intervjuer är bäst lämpad.
Studien valde att nyttja semistrukturerade intervjuer för att få en djupare förståelse för de argument som olika utvecklare lade fram. Då ett semi-strukturerat format används har intervju-ledaren möjlighet att styra frågorna och således få ut mer information från intervjuobjektet. Detta bör dock utföras med aktsamhet då styrande frågor kan påverka deltagaren svar.
Studien hade även som målsättning att hitta ett kvantitativt mönster och undersöka vilka specifika egenskaper som ansågs positiva och valde således att nyttja enkäter. Enkäterna tillät studien att generera mycket data på ett resurseffektivt sätt vilket sedan användes för att generalisera egenskaper och knyta dessa till
användningsområde och utvecklares erfarenhet[23]. Därefter drogs paralleller mellan resultatet från enkäterna och intervjuerna för att undersöka om de generaliserade egenskaperna kan återfinnas i den data som genererats av intervjuerna.
2.1.2 Förkastade metoder
De andra tillgängliga forskningsmetoderna ansågs inte vara lika lämpliga eller
effektiva för att slutföra studien och valdes således bort. Ett exempel på en metod som valdes bort är experiment eftersom studien ansåg att det vara en ineffektiv metod för att generera subjektiv data i form av hypoteser och experiment.
Vidare är design & creation en forskningsmetod där man utvecklar nya
it-produkter[4]. Design & creation handlar inte endast om att utveckla en produkt utan att även tillämpa akademiska teorier och exempelvis analysera designval medan man utvecklar en produkt. Design & creation kunde varit en bra metod för studien om
Fallstudie är en metod som övervägdes inför studien. En fallstudie innebär att
forskaren fokusera på ett specifikt fall eller en instans av det område man undersöker. Exempelvis en avdelning på ett företag. Målet med en fallstudie är således att få djup och detaljerad information om det specifika fallet[30]. En fallstudie är en annan metod som hade varit passande då studien gjorts i samarbete med ett företag och därmed hade avdelningen på företaget varit i fokus. Dock så är mycket av informationen på företaget sekretessbelagt och med hänsyn till företagets integritet valdes fallstudien bort som metod.
En annan forskningsmetod som är relevant men valdes bort är dolda
människa-datorinteraktion observationer. Dolda människa-datorinteraktion observationer är ett bra sätt för forskare att samla in data genom att observera naturliga interaktioner mellan människor och teknik[37]. Anledningen till att skribenterna valde bort denna metod är för att dolda observationer ofta kan skapa konflikter då det finns en chans att vissa människor inte vill bli observerade. Många i dagens läge ifrågasätter dolda observationer på grund av att det exempelvis ofta icke anses vara etiskt[37].
2.2 Datainsamling
Tidigare studier
Studien analyserade tidigare utförda studier för att se vilka egenskaper som tidigare identifierats och hur dessa står i relation till den data som genererats. Vidare
användes relaterade arbeten för att jämföra med studiens argument gällande analys och slutsats.
Enkät[15]
Enkätens syfte var att få in så mycket information som möjligt. Målgruppen var utvecklare från alla skicklighetsnivåer. Ett mål var att hitta ett mönster bland olika nivåer av utvecklare.
Semistrukturerade intervjuer[14]
Intervjuerna ämnar att skapa en djupare förståelse och motivera olika egenskaper och arkitekturer. Målgruppen var erfarna utvecklare som således kan ge en djupare
detaljbild. Intervjuerna var semistrukturerade vilket innebär att frågorna är löst definierade. Syftet var att skapa en diskussion och få intervjuobjektet att gå in på djupet om frågan.
Online-material
Studien använde sig utav online-material såsom bloggar och officiell dokumentation för arkitekturer och ramverk för att kunna få en djupare förståelse kring dessa samt kunna beskriva dem för läsaren.
2.2.1 Litteraturstudie
Studien använde främst ACM digital library, Google Scholar och IEEE för att söka efter relaterade arbeten och relevant litteratur. Initial valde studien att göra en bred
sökning inom forskningsområdet. Breda sökbegrepp likt MVC, MVVM, Ruby on Rails, Redux och Flux användes främst. Detta gjordes för att snabbt skapa sig en överblick av forskningsområdet och därefter påbörja läsandet av sammanfattningar (eng. abstract). Sedan valdes relevant forskning ut och sammanfattades i separata dokument.
Då skribenterna skapat en övergripande bild av både de tekniker och forskningen inom området övergick studien till en mer djupgående litteraturstudie och adderade mer relevanta sökord såsom: survey, pros and cons, data flow, documentation, properties, relevancy, separation, popularity, architecture, software, web etc. Detta gjordes för att specificera sökresultaten och få resultat som kunde användas till studiens forskning. Dessa resultat sammanfattas och presenteras sedan under relevant område i studien.
2.2.2 Sökprocess
ACM digital library, Google Scholar och IEEE användes främst för att söka relevant litteratur till studien. De sökord som användes bestod bland annat av: MVC,
Model-View-Controller, MVVM, Model-View-ViewModel, Flux, Redux, Ruby on Rails, Separation between logic and UI, software design, design properties, survey, pros and cons architecture m.m.
2.2.3 Semistrukturerade intervjuer
Då studien ämnade att använda sig utav kvalitativa metoder för att besvara fråga två respektive fråga tre har semi-strukturerade intervjuer valts som metod. När
intervjuerna utfördes fick intervjuobjekten svara på öppna frågor som utgick från områden som rörde studien. Semi-strukturerade intervjuer ämnar att ge en djupare förståelse kring områden då man låter intervjuobjekten tala fritt och svara så
detaljerat och öppet som möjligt[18]. Vidare ställdes följdfrågor som inte var förutbestämda utan ställdes beroende på intervjuobjektets svar[18].
Samtliga intervjuobjekt kom från samma företag och kunde således ha en liknande bias som grundas i gemensamma utbildningar, erfarenheter och policys från Företaget i fråga.
De semistrukturerade intervjuerna som utfördes under studien bestod av fyra
intervjuobjekt [14]. Studien utgick från fasta frågor där intervjuobjektet fick tala fritt. Vidare ställdes även följdfrågor utifrån intervjuobjektets svar.
2.2.4 Enkät
Digitala enkäter används för att initialt få en bred bild kring ämnet[15]. Digitala
enkäter är lämpliga för studien då det är ett enkelt och kostnadseffektivt sätt att nå ut till en stor grupp utvecklare.
Datainsamlingen analyserades främst kvalitativt, studien valde även att försöka få fram kvantitativa mönster i den information som tagits fram. Med hjälp av den
kvalitativa insamlingen kan en djupare förståelse definieras medans den kvantitativa delen tar fram mönster och relationer samt undersöker vilka arkitekturer och ramverk respondenterna är bekanta med.
Majoriteten av de individer som deltog i enkäten var mjukvaruingenjörer. Trots att många plattformar nyttjats för att skicka ut enkäten såsom Facebook-grupper, Discord-grupper samt grupper på företag så lyckades enkäten endast samla in 17 svar.
2.3 Urval
För att nå ut till så många utvecklare som möjligt distribuerades enkäten ut digitalt med hjälp av Google Forms. Enkäten publicerades på ett utvecklingsföretag i Lund, sociala medier likt Facebook-grupper och Discord-kanaler. Intervjuerna gjordes på företaget i fråga där fyra anställda med varierande erfarenhet inom programmering deltog. De olika deltagarna jobbade inom Webbutveckling,
desktop-applikationsutveckling, backend-utveckling och microservice-utveckling.
Urvalet begränsades till forum där sannolikheten för att personerna har kompetens inom datavetenskap är hög. Strategin som använts kan liknas vid ett obundet slumpmässigt urval, detta innebär att en en del av populationen väljs ut
slumpmässigt för att sedan användas som ett stickprov. Då det visade sig vara svårt att få utvecklare att delta i enkäten valde studien att inte göra någon särskild
validering av personerna i fråga utan förlitat sig på de kanaler som använts för att dela ut enkäten. Vidare var enkäten öppen, dvs. att det inte fanns några restriktioner som kräver att användare svarade på samtliga frågor. Detta främst då restriktioner likt detta kan leda till att deltagare hoppar över hela enkäter och studien förlorar således data på andra frågor.
3.0 Resultat
3.1 Sammanställningar och fynd ur litteraturstudien
Studien tog del av de tio designprinciper som Jakob Nielsen tagit då han studerat designprinciper[6][7][8][9]. Här nämns följande:
Visibility of system status - Användargränssnittet skall hålla användaren informerad om systemets tillstånd
Match between system and the real world - Användargränssnittet ska spegla verkligheten och beskrivas på ett språk som användaren kan tolka.
User control and freedom - Det ska finnas möjlighet att anpassa mjukvaran och ångra inställningar och tillstånd som tidigare redigerats.
Consistency and standards - De konventioner som gäller för aktuell plattform ska nyttjas.
Error prevention - Systemet ska vara byggt på ett sådant sätt som förhindrar fel att uppstå.
Recognition rather than recall - Det ska inte behövas ett behov från användaren att memorera systemets funktioner. Dessa bör lätt igenkännas.
Aesthetic and minimalist design - Användargränssnittet ska endast presentera den data som är aktuell och användbar.
Help user recognise, diagnose and recover from errors - Felmeddelande ska vägleda användaren till en lösning och framgå på ett språk som är enkelt att förstå.
Help and documentation - Information för att navigera och orientera sig i systemet ska vara lättillgänglig och visa steg för steg hur användaren ska gå tillväga för att uppnå ett visst mål.
Dessa designprinciper beskriver främst hur ett grafiskt användargränssnitt ska implementeras för att vara så tillfredsställande för användaren som möjligt.
Studien tog del av en survey som utfördes i Pakistan[5]. Surveyn i fråga kommer bland annat fram till att det är väldigt viktigt att arkitekturer vidareutvecklas tillsammans med ett system och dokumenteras väl. Dokumentation anses som en viktig del av arkitekturen. Författarna av studien tar upp hur ett projekts framgång påverkas av användningen och valet av rätt arkitektur. Studien förklarar att när en arkitektur väljs på rätt sätt och när ett projekt är stöttat av en god arkitektur så leder detta oftare till ett lyckat projekt gentemot när valet av arkitektur inte tas hänsyn till. Studien
beskriver även vikten av dokumentation vilket kan användas som argument inför denna studie.
Vidare beskriver studien “Software Architecture: A Survey and Classification” hur arkitekturer är ett slags behov som baseras i kvalitativa kriterier som tagits fram av användare och utvecklare av ett system. Studien behandlar MVC och beskriver bland
användargränssnittet. Vidare beskrivs negativa egenskaper så som ökad komplexitet. I ovan nämnda studie kan man hitta generella fördelar som återspeglas i flera olika arkitekturer. Dessa innefattar bland annat: återanvändning, separation av
intresse/användningsområde, flexibilitet. På samma sätt går det att hitta mönster i de negativa egenskaperna: prestanda, komplexitet, testing, debugging samt onödigt arbete[24].
Den fallstudie som utfördes i studien “A Journey Through the Land of Model-View-*
Design Patterns”[28] behandlar MVC, MVVM samt MVP ur MV-familjen. Stuiden beskriver hur samtliga arkitekturer utgår från ett gemensamt mål - att separera intressen/användningsområdet då man tar fram en applikation med ett
användargränssnitt. Studien sammanfattar olika för- och nackdelar och nedan presenteras delar av resultatet för MVC samt MVVM.
MVC
Studien beskriver hur MVC är ett bra val för webbapplikationer då vy- och kontroll-lager är naturligt separerade i denna miljö. Samtidigt kritiseras MVCs
förmåga att hantera vy-lagrets tillståndslogik, det vill säga att MVC har problem med att hantera logik i vy-lagret vilket görs i flera populära webbramverk. Detta leder således till att det kan bli svårt att använda en strikt MVC-modell med ett ramverk.
MVVM
Studien beskriver främst hur MVVM kan hantera flera vyer för samma data. Samtidigt erbjuder MVVM en stark separation av intressen/användningsområden inom
applikationen. Studien kritiserar dock MVVM för att förlita sig på underliggande teknik samt att “observer synchronisation” kan resultera i försämrad prestanda.
Både artikeln “Using taps to separate the User interface from the application code[29]” och artikeln “Enforcing Strict Model-View Separation in Template Engines[17]” tar upp MVC och beskriver dess för- och nackdelar samt beskriver vad MVC är bra att
användas till. Artiklarna tar bland annat upp inkapsling, underhåll och
arbets-separation som fördelar. Vidare beskriver artiklarna negativa egenskaper såsom att MVC kan vara komplext och att en del utvecklare har svårt att veta var gränsen mellan controller och view bör vara. Båda artiklarna tar upp MVC och beskriver den som välkänd.
Artikeln “Will Software Developers Ride Ruby on Rails to Success?[32]” tar bland annat upp fördelarna med Ruby on rails främst med dess snabbhet i konfiguration. Artikeln citerar Curt Hibbs, en mjukvaruingenjör som menar att med hjälp av Rails kan en utvecklare uppnå samma resultat på samma tid som ett helt team ifall teamet hade använt Java för att konfigurera ett projekt. Vidare förklarar en chef av ett
utvecklingsföretag att det tog 10% av tiden att konfigurera ett projekt med Rails än vad det brukade göra med Java. Vidare förklarar personen i fråga att koden för
konfigurationen var 25% av koden konfigurationen brukade ha med Java. Artikeln tar vidare upp förgenererad kod och förklarar att det är en stor fördel när till den tid det tar för att konfigurera och initiera projektet. Artikeln “Distributed Performance Systems
using HTML5 and Rails[33]” beskriver fördelarna med Rails snabba konfiguration. Artikeln beskriver att Rails löser problem med skalbarhet (scalability),
testbarhet(testability), konfiguration och underhåll mycket väl på grund av egenskaper såsom för-genererad kod.
Vidare beskriver artikeln “Case studies on Analyzing Software Architectures for Usability[34]“ ett problem med användbarheten efter att ett projekt satts i drift och förklarar att det är kostsamt att korrigera och skriva om stora bitar kod i efterhand. Därefter behandlar artikeln användbarhet och menar att arkitekturen bakom ett projekt kan hjälpa till att lösa problem gällande användbarheten i förhand om arkitekturen stödjer det.
3.2.0 Åldersfördelning
Majoriteten av de som deltog i enkäten var mellan 20-25 år gamla, det var 52,9% som denna åldersgruppen bestod av. 35,3% av deltagarna var i åldersgruppen 26-35 år och 11,8% av deltagarna var under 20 år gamla. Inga individer som var 36 år eller äldre deltog i enkäten.
Figur 6: Åldersgrupper på deltagare.
3.2.2 Demografi
Majoriteten av de svar som enkäten samlat in kom från Sverige, detta motsvarade 72,7% av samtliga deltagare i undersökningen. Utöver detta så var det 9,1% av svaren som kom från individer som var bosatta i Indien, Pakistan och Nigeria.
3.2.3 Erfarenhet
Erfarenhet bland de mjukvaruutvecklare som svarade på enkäten varierade.
Respondenterna bestod av allt från utvecklare med endast elementära kunskaper till seniora utvecklare. Majoriteten av deltagarna hade mellan 1-3 (29,4%) års erfarenhet och 4-6 (29,4%) års erfarenhet av mjukvaruutveckling. Vidare hade 11,8% av
deltagarna ingen erfarenhet och 17,6% av deltagarna mindre än ett års erfarenhet av mjukvaruutveckling. 11,8% av deltagarna hade mellan 11-20 års erfarenhet av mjukvaruutveckling. Inga individer med 21 eller fler års erfarenhet deltog i enkäten.
Figur 7: Deltagare kategoriserat i erfarenhet av mjukvaruutveckling.
3.2.4 Olika arkitekturer
Vid frågan ‘What different architectures/models for separating user interface are you
familiar with?’ hade majoriteten (47,1%) av deltagarna valt MVC. Utöver MVC nämnde fyra personer andra arkitekturer inom MV-familjen. Ett fåtal personer nämnde
arkitekturer som inte var inom MV-familjen och de nämnde då arkitekturer så som Observer-pattern, JAM, RESTful services, event-driven architecture och PAS. Det var fyra deltagare som valde att inte besvara frågan för att de inte kände till några
arkitekturer.
Figur 8: Andel arkitekturer nämnda av deltagare.
3.2.5 Olika ramverk
Vid frågan ‘What different architectures/models for separating user interface are you
familiar with?’ var svaren varierade. Dock hade majoriteten (17,9%) valt Ruby on Rails.
Figur 9: Andel ramverk nämnda av deltagare.
3.2.6 Viktiga egenskaper i en arkitektur
Frågan ‘What properties do you find important in a design architecture’ genererade svaren enkelhet, skalbarhet och kvalitet. De som svarade på enkäten skrev bland annat “Easy to understand and implement” och “Simplicity and scalability”. Majoriteten
ovanstående. Vidare fanns det ett fåtal individer som svarade “Loosely coupled” och “Decoupled”. Det var även tre personer (17,6%) som valde att inte svara på frågan.
3.2.7 Viktiga egenskaper i ett ramverk
Enkäten ställde frågan “What properties do you find important in a framework?”. Av de 17 svar som samlats in kunde åtta svar härledas till enkelhet av användning. Det fanns således ett tydligt mönster bland deltagarna och deras önskemål om att ett ramverk bör vara enkelt att använda och komma igång med. Vidare nämner flera deltagare att det bör finnas väldokumenterade manualer för ramverket och det bör finnas guider som hjälper utvecklare komma igång från start. Ett av svaren nämner “no black magic” vilket studien tolkade som att den hjälp som ramverket bidrar med bör vara uppenbar och inte ske bakom kulisserna. Funktioner och autogenererad hjälp bör alltså vara dokumenterad.
Flexibilitet, modularitet och skalbarhet är tre nyckelord som förekom frekvent i enkäten. Deltagarna ansåg alltså att det var viktigt att ramverket erbjuder lösningar för större projekt som vanligen kräver just flexibilitet, modularitet och skalbarhet för att vara effektiva.
3.2.8 MVC
Enkäten ställde frågan “How hard is Model-View-Controller (MVC) to learn in your
opinion?” Studien visade att de flesta finner MVC relativt lätt att lära sig. De personer som svarade medelmåttigt, var främst utvecklare med 1-3 års erfarenhet och bör således ses som relativt nya inom systemutveckling. De utvecklare som valde lätt som alternativ kunde hittas i erfarenhetsgrupper både mellan 1-3 år samt 4-6 års
erfarenhet
Figur 10: Diagrammet illustrerar deltagarnas uppfattning av svårighetsgrad med MVC.
Enkäten undersökte därefter vilka fördelar utvecklare ansåg finnas hos MVC. Flera utvecklare påpekade att MVC var lätt att förstå och använda sig utav. Många menade att “decoupling”, isoleringen av olika moduler var en stor fördel. En deltagare svarade “Makes the application easier to maintain and switch loosely coupled components. eg
the interface” och menade således att det var enkelt att byta ut användargränssnittet hos en applikation utan att påverka resterande delar i systemet. Detta bekräftades från fler deltagare som exempelvis nämner “Good to separate business logic from the
user interface, making it easier to replace a UI that goes old/out of style”. Vidare nämnde en annan deltagare att modulariteten och isolationen av intresse tillåter flera utvecklare att arbeta på samma applikation samtidigt då arbetsområdet blir isolerat.
Därefter behandlade enkäten de negativa egenskaperna hos MVC. En del utvecklare nämnde att MVC kan vara onödigt att implementera i mindre projekt då det inte är värt den ökade komplexiteten och tidsåtgången som krävs för att strukturera ett projekt enligt MVC. Ett av enkätsvaren nämnde hur en liten applikation snabbt blivit ett stort projekt enligt personens tidigare erfarenhet. En av deltagarna svarade “Front
and back end get tied together in the language or framework you're using. Migrations would require changing a lot more, instead of having your front-end making the same API calls.”. Personen i fråga menade alltså att MVC inte tillåter kommunikation över olika plattformar vilket exempelvis kan ge problem om man vill migrera en
desktopapplikation till ett webbgränssnitt. Vidare föreslog personen i fråga ett API som kan sköta kommunikationen mellan de olika plattformarna.
Andra utvecklare nämnde att MVC ofta är svårare i praktiken än vad teorin speglar.
3.2.9 MVVM
Vidare ställdes frågan “How hard is Model-View-Viewmodel (MVVM) to learn in your
opinion?”. Enkäten visade att större delen av deltagarna inte kände till MVVM eller saknade erfarenhet av MVVM. 41,2% av deltagarna hade erfarenhet av arkitekturen och upplever delade meningar kring svårigheten.
Figur 11: Diagrammet illustrerar deltagarnas uppfattning av svårighetsgrad med MVVM.
Därefter ställdes frågan “In your opinion, what are the advantages with MVVM?” var på tre svar kan ses som giltiga. Utvecklarna nämnde användarvänlighet samt
återanvändning av vy-modeller. Ett av svaren berättade “The view needs to know very
little about the implementation of the view model. The view model needs to know nothing about the implementation of the view.”.
Likt föregående arkitektur ställdes sedan frågor om de negativa egenskaperna hos arkitekturen. I detta avseende kunde två svar ses som giltiga då en större andel av
implementationen av MVVM kunde vara meningslös för mindre grupper eller projekt. Samt att där fanns ett starkt samband (coupling) mellan vy och vymodell oavsett.
3.2.10 Flux
Därefter behandlade enkäten arkitekturen Flux och ställde frågan “How hard is Flux to
learn in your opinion?”. Majoriteten av deltagarna kände inte till Flux eller saknade erfarenhet av arkitekturen.
Figur 12: Diagrammet illustrerar deltagarnas uppfattning av svårighetsgrad med Flux.
Vidare undersökte enkäten vilka fördelaktiga egenskaper Flux besitter. Enkäten fick två svar som kunde anses som bidragande till studien. En av deltagarna nämnde “Unidirectional dataflow” vilket innebär att dataflödet är enkelriktat i applikationen. Medans den sista angav “GUI layout and content as a pure function of the store makes
rendering easy to reason about. Single action dispatch entry point makes events easy to reason about. That the GUI is a rendition of the store rather than something it
communicates with via a broker is conceptually satisfying.”
Därefter ställdes frågan “In your opinion, what are the disadvantages with Flux?”. Studien kunde gå vidare med två svar av de fem som angivits. Det första svaret angav att arkitekturer kräver för mycket kod för enkla uppgifter i applikationen. Det sista svaret nämnde: “In the web browser, the function generating the GUI is facilitated by an
abstraction layer generalizes the problem of updating the DOM in an efficient manner, and the general solution is not always very efficient. Maintaining all state in the store becomes cumbersome and the solution put forward by libraries like React—using component-local state—complicates rendering.”.
3.2.11 Ruby on Rails
Enkäten behandlade frågan “How hard is Ruby on Rails to learn in your opinion?”. Majoriteten (58,8%) av deltagarna svarade att de inte kände till eller saknar erfarenhet av Rails-ramverket. 5,9% av deltagarna svarade väldigt enkelt respektive enkelt.
Utöver detta svarade 11,8% medelmåttigt och 17,6% av deltagarna svarade att de inte visste.
Figur 13: Diagrammet illustrerar deltagarnas uppfattning av svårighetsgrad med Ruby on rails.
Vidare undersökte enkäten de egenskaper som ansågs vara fördelaktiga med
Rails-ramverket. Först ställdes frågan “In your opinion, what are the advantages with
Ruby on rails?”. Enkäten fick fram två svar som ansågs vara giltiga för att användas i studien. En deltagare valde att svara “MVC” vilket syftar till att Ruby on rails är
baserat på Model-View-Controller arkitekturen och har därmed komponenter som inte är kopplade till varandra vilket gör det lättare för utvecklare att byta ut och ta bort moduler inom systemet. Den andra deltagaren svarade “Batteries included” vilket tolkades av studien som att ramverket Ruby on Rails hjälper utvecklare med starten av ett projekt vilket betyder att utvecklare inte måste spendera tid på konfigurationer och beroenden för att kunna börja koda.
Vidare ställdes frågan “In your opinion, what are the disadvantages with Ruby on
rails?” där enkäten endast fick ett svar som anses vara giltig för studien. Deltagaren svarade:
“Batteries fixed in place. Hides complexity behind configuration and a scaffolding
command language. Hides database interaction behind ORM (Object relational
mapping). Complexity and performance bottlenecks still exist but are harder to reason about and address because they were largely expressed in terms of the command and configuration languages and especially the ORM. In my experience this makes simple problems (like getting the GUI to reflect some database state) trivial at the expense of making hard problems (e.g. optimizing queries) harder.”.
Med detta menade deltagaren att hela konfigurationen av ett projekt sker bakom kulisserna och gör det hela mer komplext. Deltagaren menade att simpla problem blir enklare medan svåra problem blir ännu svårare.
3.2.12 Redux
Enkäten behandlade ramverket Redux och ställde frågan “How hard is Redux to learn
in your opinion?”. Majoriteten(52,9%) av deltagarna svarade att de inte kände till det eller hade någon erfarenhet av Redux. 11,8% av deltagarna svarade väldigt enkelt och 5,9% svarade enkelt. Vidare svarade 17,6% medelmåttigt samt 11,8% att de inte visste.
Figur 14: Diagrammet illustrerar deltagarnas uppfattning av svårighetsgrad med Redux.
Därefter undersökte enkäten vad som ansågs vara fördelaktigt med Redux och ställde frågan “In your opinion, what are the advantages with Redux?”. Enkäten genererade tre svar som ansågs vara giltiga. De två första deltagarna gav likvärdiga svar där en skrev “Easy to manage global state” och den andra skrev “Easy to access global variables”. Detta tolkades som att det var fördelaktigt att Redux använder globala tillstånd och variabler som ligger i modellen. Den tredje deltagaren svarade “Makes state and state
changes very easy to reason about and debug. The basic pattern can be implemented and demonstrated in tens of lines of code without the support of an existing library or framework.”
Vidare ställdes frågan “In your opinion, what are the disadvantages with Redux?”. Enkäten genererade fyra svar som ansågs vara giltiga. Den första deltagaren svarade att Redux endast är användbart för stora projekt, detta tolkas som att användningen av Redux för små projekt kan lägga till onödig komplexitet när det inte behövs. En annan deltagare tog upp att det saknas fullständig dokumentation vilket kan göra det svårare för utvecklare att förstå hur Redux fungerar. Utöver detta tog deltagaren upp att store:n återställs när man laddar om webbläsaren som denna person anser vara en negativ aspekt i Redux. En annan deltagare svarade att det finns för mycket
boilerplate-kod för simpla uppgifter vilket tolkades som att det ofta förekommer onödig kod för funktioner etc. Den sista deltagaren svarade “Immutable updates can be
expensive in plain Javascript in cases such as insertion into very large arrays.”. Här tog personen upp de oföränderliga tillstånden som man har inom Redux, deltagaren
menar att det kan bli väldigt kostsamt att ha oföränderliga tillstånd om man programmerar i vanlig Javascript.
3.3 Intervjuer
3.3.1 Ålder och arbetsområde
Intervjuobjekten bestod av fyra deltagare mellan 23-40 år, samtliga arbetade inom samma företag men under olika avdelningar och ansvarsområden. Deltagarna utvecklade främst webbapplikationer och hade erfarenhet från utveckling av desktop-applikationer och backend-utveckling. En av deltagarna arbetade med microservices-backend.
3.3.2 Kännedom arkitektur
Intervjuns deltagare var samtliga bekanta med Model-View-Controller. En del nämnde olika konstellationer av MV-familjer likt MVP och MVVM. En av deltagarna nämnde att han slutat studera olika designmönster och fokuserade istället på att separera olika ansvarsområde då han programmerar.
3.3.3
Kännedom ramverk
Flera intervjuobjekt nämnde React Redux-kombinationen då denna kombination främst används utav Företaget. Utöver Redux nämndes även Laravel, Django, Ruby on rails, Knockout, Spark, Backbone etc.
3.3.4
Valet av arkitektur och ramverk
Det första intervjuobjektet såg att ett ramverk eller en arkitektur bör vara
väldokumenterad och uppdateras i takt med språket som speglas. Javascript som uppdateras relativt frekvent behöver alltså ramverk som uppdateras för att nyttja de senaste funktionerna. Personen påpekade att det var viktigt att det är lätt att förstå arkitekturen eller ramverket som används. Vidare ansåg det andra intervjuobjektet att man bör fundera på hur systemets framtid ser ut, ett projekt som avses att skalas i framtiden bör välja en arkitektur som är lämplig för att just skala en applikation. Personen i fråga nämnde att man inte bör lägga för stor vikt på implementation av en arkitektur i mindre projekt då detta kan vara onödigt tidskrävande.
Den tredje deltagaren nämnde att det inte finns någon anledning att utgå från en fast bestämd lösning utan man bör utgå från projektet förutsättningar och göra sina val av design och verktyg utifrån detta. Vidare ansåg personen att det är viktigt att samtliga utvecklare förstår hur den valda arkitekturen fungerar. Detta för att samtliga ska kunna tala samma språk inom projektet och förstå hur koden fungerar samt hur dataflödet bör tydas. Det sista intervjuobjektet ansåg att det var väldigt viktigt att få en bra struktur på ett projekt. Särskilt då personen i fråga arbetar agilt och
kontinuerligt lägger till nya funktioner utifrån kundens önskemål. Han nämnde även att en bra struktur lämpar sig då man utvecklar inom nya produktområde där man tidigare saknar erfarenhet.
För att hitta rätt arkitektur eller ramverk till ett projekt används främst olika former av digital media för att samla information. En av deltagarna nämnde att han läste på olika forum likt Reddit för att skapa sig en bild utav hur andra utvecklare upplever dessa verktyg. En annan nämnde att han läste artiklar som “lägger sig i bakhuvudet” som man senare kan gå tillbaka till vid behov. Därefter var flera deltagare överens om att man lär sig enklast genom att prova ett verktyg, ett exempel kan vara att skapa ett litet projekt och genomföra detta med hjälp av verktyget för att på så vis skapa sig en förståelse och uppfattning av verktyget. Vid nya projekt var valet av arkitektur inte det viktigaste enligt flera utvecklare, de menade att man ofta faller tillbaka till något man tidigare arbetet med för att snabbt få fram ett resultat. Ett av intervjuobjekten sade: “Det är väl snarare så att om jag ska starta ett projekt och har en idé så tar jag bara
något jag är bekväm med och jag vet är bra.“.
3.3.5
Modularitet och testbarhet
Det första intervjuobjektet ansåg att modulariteten i ett system var väldigt viktigt. Han förklarade att om modulariteten hos ett system kan påverka testbarheten negativt så är det ändå något att föredra då det är enklare att kontrollera koden i efterhand och redogöra för vad en moduls ansvar är. Vidare svarade det andra intervjuobjektet att han har en tendens till att “hoppa in” i ett projekt och börja koda. Vidare förklarar personen i fråga att det ofta händer att han av misstag lägger in logik i vy-lagret då han vill se resultat så snabbt som möjligt. Personen i fråga förklarar att han inte tenderar att fokusera mycket på “smågrejer” som val av arkitektur eller testbarhet och modularitet utan han brukar skriva all kod i en stor modul som han senare bryter ut vid behov.
Det tredje intervjuobjektet förklarade att han tyckte testbarhet var viktigt för ett system. Personen i fråga menade även att genom att bryta upp systemet i olika moduler läggs komplexitet till som gör det svårare för framtida generationer av ingenjörer som ska jobba med samma system. Han menade att testbarhet och underhållbarhet var viktigare än modularitet i många fall. Det sista intervjuobjektet ansåg att modulariteten, även om det påverkar testbarheten negativt, ofta är viktigare än testbarheten i ett system.
När det kommer till modularitet och den påverkan det har på komplexiteten och testbarheten av ett system så ansåg merparten av intervjuobjekt att testbarheten var bra men modulariteten är viktigare i många fall. Endast ett intervjuobjekt svarade att testbarheten kan vara viktigare då modulariteten lätt kan göra ett system mer
komplext och att han tycker att det är “viktigare att den [applikationen] är enklare”. Alla intervjuobjekt hade en gemensam uppfattning om att det beror på vilken typ av system man tänker bygga och därmed gör sitt val efter sina förutsättningar. Ett intervjuobjekt svarade “Jag tror på många sätt och vis att modulariteten är jävligt bra,
man vill gärna ha det tydligt vad olika saker gör för någon slags läsbarhet i koden. Sen att det kan resultera i att det blir svårare att testa det är en annan femma.”
3.3.6 Dataflöde
Den första intervjudeltagaren nämnde att han ansåg att det är viktigt med ett tydligt dataflöde. Huruvida detta återges i form av UML[21] eller i textformat spelar ingen
större roll. Vidare ansåg personen att det var bra med ett enkelriktat dataflöde då man kan följa koden och se var datan ursprungligen kommer ifrån. Här nämns även att det är “superbra ur ett felsöknings-perspektiv” då man kan följa ledet och förstå vad som faktiskt händer.
Vidare ansåg det andra intervjuobjektet att ett enkelriktat dataflöde var en fördel, främst då man kan följa sin data vilket gör att det blir lättare att testa. Personen nämnde även att det kan bli svårt att kontrollera hur och när en viss data blir
manipulerad om man inte kan följa flödet enkelt. Den tredje deltagaren nämnde att ett dubbelriktat dataflöde gör att vad som helst kan hända i applikationen samt att
komponenter du inte trodde påverkades helt plötsligen slutar fungera. Det fjärde intervjuobjektet menade att så länge olika delar av systemet behandlar dataflödet på samma sätt så får applikationen en bra uppdelning.
3.3.7
Inlärningskurva
Inlärningskurvan av en arkitektur eller ett ramverk kan påverka användningen av sagda verktyg. Både intervjuobjekt ett och tre höll med om att då inlärningskurvan för en arkitektur eller ett ramverk är för brant så använder färre utvecklare det,
alternativt så mister användaren motivering att använda verktyget då det blir för svårt. Intervjuobjekt tre svarade bland annat med “Alltså ju svårare det är desto mindre [folk
finns det som använder den]. Det kommer ju finnas folk som ger upp som ger sig på det.”.
Intervjuobjekt tre ansåg att detta leder till att det finns färre blogginlägg och tillgång till hjälp för nya utvecklare vilket leder till att ännu färre utvecklare använder sig utav arkitekturen eller ramverket. Intervjuobjekt fyra höll med om att enkelheten är viktig för populariteten av en arkitektur eller ett ramverk. Personen i fråga beskrev även React+Redux som är det han använder sig utav, och att enkelheten är en faktor till varför React+Redux är så populärt bland utvecklare.
3.3.8 Vad gör något populärt?
Det första intervjuobjektet menade att en viktigt faktor till ett verktygs framgång är enkelheten att förstå konceptet. Personen ansåg att MVC har en tydligt struktur och det är enkelt att förstå innebörden av en vy, kontrollenhet samt modell. Vidare påpekade personen att utvecklare med en objektorienterad bakgrund resonerar bra med dessa koncept.
Det andra intervjuobjektet ansåg att marknadsföring och “hajp” är bidragande faktorer till en arkitektur eller ett ramverks framgång. Personen nämnde React som ett
exempel och menar att många blir nyfikna på React för att ett stort, tech-ledande företag som Facebook ligger bakom projektet. Vidare ansåg intervjuobjektet att det troligen var liknande faktorer som bidrog till MVCs framgång och menar att det säkerligen fanns fler alternativ som var likvärdiga. Personen ansåg att utvecklare har en tendens att marknadsföra nya tekniker som de själva använder och på så vis bidrar till ett verktygs popularitet.
3.3.9
För-genererad kod
För-genererad kod används ofta av ramverk för att göra början av ett projekt enklare för utvecklare. Genom att förse utvecklare med grundkod, grundfunktioner eller beroenden och konfiguration så kan utvecklare snabbt komma igång och se resultat på skärmen. När frågan om för-genererad kod ställdes till intervjuobjekt ett så fick studien svaret att för-genererad kod kan vara väldigt bra speciellt för nya utvecklare som inte förstår sig på exempelvis ramverket än. Personen i fråga utvecklade genom att säga att man samtidigt offrar kunskap vilket gör att man kanske inte kan lösa fel eller liknande som uppstår i framtiden då man inte förstår sig på ramverket helt. Intervjuobjekt ett förklarade vidare att han tyckte att man borde få välja hur mycket för-genererad kod man får från arkitekturen eller ramverket, han sade bland annat “Ja man ska absolut kunna välja om man vill ha det eller inte. En del vill göra det på sitt
eget som då dom är mer bekväma med detta och vad det innebär. Så valfriheten är absolut vital.”.
Intervjuobjekt två ansåg däremot att för-genererad kod är väldigt bra och att man som utvecklare oftast inte behöver bry sig om vad som sker i bakgrunden. Intervjuobjekten tre och fyra höll med intervjuobjekt ett att det kan vara bra men att det samtidigt är dåligt då man inte förstår det man gör till fullo. Bland annat så tog intervjuobjekt tre upp ett exempel med att det är stor chans att man får Ruby on rails-utvecklare istället för ruby-utvecklare och React-utvecklare istället för webbutvecklare om man blir försedd med för mycket för-genererad kod.
De flesta av intervjuobjekten höll med om att för-genererad kod är generellt positivt så länge det inte är för mycket och påverkar utvecklarens förståelse kring ramverket eller arkitekturen. Enkelheten av att få hela grunden färdigt gör att man snabbt kommer igång men tar även från din egen kunskap är något de flesta håller med om.
