Procedurers inverkan på
kodförståelse i Java
En studie med eye-tracking
KIM YTTERBERG
KTH
Procedurers inverkan på
kodförståelse i Java
- en studie med eye-tracking
KIM YTTERBERG
Civilingenjör Datateknik Datum: 6 juni 2018 Handledare: Dilian Gurov Examinator: Örjan Ekeberg
Engelsk titel: The impact of procedures in Java on code readability - a study with eye-tracking
iii
Sammanfattning
Abstract
In the software life cycle, a great amount of time is spent on the final stage, the maintenance phase. At this stage, the software is fully de-veloped and needs continuous maintenance to ensure constant func-tionality and efficiency of the software [25]. It is therefore important for the software to be as readable as possible since other programmers might start working on the software. It is also important to keep the code readable to quickly troubleshoot the code. Procedures are taught as a way to keep the code structured and easy to read among other ab-stractions. In recent years, the study of code readability has gained an increasing popularity and with the help of eye-tracking it has allowed for the study of readability in a more concrete way.
Innehåll
1 Introduktion 1 1.1 Introduktion . . . 1 1.1.1 Frågeställning . . . 1 1.1.2 Syfte . . . 1 1.1.3 Hypoteser . . . 2 1.1.4 Avgränsningar . . . 2 2 Bakgrund 3 2.1 Teori . . . 3 2.1.1 Begrepp . . . 32.1.2 Procedurer - abstraktion av kontrollflöde . . . 4
2.1.3 Mjukvaruunderhåll . . . 4
2.1.4 Läsbarhet i litteratur . . . 5
2.1.5 Läsbarhet av kod . . . 6
2.1.6 Eye-tracking - hur fungerar det . . . 8
2.1.7 Mätning av eye-tracking . . . 8
2.1.8 Läsbarhet av kod med eye-tracking . . . 9
2.1.9 Liknande undersökningar . . . 9 3 Metod 11 3.1 Forskningsmetodik . . . 11 3.2 Utrustning . . . 12 3.3 Datainsamling . . . 13 3.4 Layout av AOI . . . 14 3.5 Kodsegment . . . 16 3.6 Analys av data . . . 19
4 Resultat och Analys 20
5 Diskussion 28
5.1 Felkällor . . . 28
6 Avslutning 30
Litteratur 31
Kapitel 1
Introduktion
1.1 Introduktion
För en programmerare är det viktigt att göra koden så läsbar som möj-ligt där man genom ett flertal vedertagna riktlinjer försöker uppnå det-ta så bra som möjligt. Dessa riktlinjer innefatdet-tar att dela upp koden i procedurer (så kallade metoder i Java) använda variabler med bra, lätt-förstådda namn, samt hålla formateringen av koden konsekvent för att undvika trasslig och ostrukturerad kod [30]. Genom att inte följa dessa riktlinjer kan det medföra högre kognitiv belastning för förvaltaren av koden då komplexiteten att läsa koden ökar [19]. Det finns flera sätt att mäta läsbarhet, en metod som börjar användas mer och mer i studier är användningen utav eye-tracking då man kan se exakt hur folk läser.
1.1.1 Frågeställning
Med detta som bakgrund ämnar jag undersöka ifall läsbarhet av kod verkligen påverkas beroende på procedurers förekomst, och ifall detta skiljer sig mellan erfarna och nya kodare, med hjälp av eye-tracking. Specifikt är forskningsfrågan: "Hur påverkas läsbarheten av kod be-roende på procedurers längd och förekomst, och varierar detta med programmeringserfarenhet".
1.1.2 Syfte
Syftet med den här studien är att med hjälp av en eye-tracker under-söka skillnaden i läsbarhet av kod som är monolitisk eller uppdelad
med procedurer.
1.1.3 Hypoteser
Med studien Beauty and the Beast: on the readability of object-oriented ex-ample programs av Börster et al. [4] som grund kommer det vara lät-tare att läsa kod uppdelad i procedurer jämfört med ett monolitiskt block av sekventiella satser. Dock kommer det vara intressant att se hur nybörjare hanterar detta jämfört med erfarna programmerare då man funnit att dessa läser kod mer sekventiellt jämfört med erfarna programmerare. Därför är en hypotes att nybörjare kommer ha lättare att läsa kod som har en monolitisk struktur framför en procedurupp-delad sådan.
1.1.4 Avgränsningar
I denna studie kommer inte fler än tio deltagare vara med då tiden är begränsad. Kommentarer, namngivning av identifierare samt andra sätt att ta fram läsbarheten av kod (såsom SRES m.m) kommer inte att behandlas.
Genom att undersöka huruvida det är skillnad i läsbarhet av kod mellan nybörjare och erfarna kodare, beroende på om koden är uppde-lad i anrop till procedurer med specifika uppgifter gentemot ren mo-nolitisk kod utan anrop till procedurer, kan man dra lärdom om hur man kan lära ut programmering för nybörjare och ifall det experimen-tellt stämmer att procedurer förenklar läsbarhet av kod.
Kapitel 2
Bakgrund
I detta kapitel kommer teorin bakom läsbarhet och eye-tracking be-handlas varefter syftet, frågeställning, avgränsningar och hypoteser presenteras.
2.1 Teori
I denna sektion kommer teori som hör eye-tracking att behandlas till-sammans med läsbarhet i kod och i naturliga språk.
2.1.1 Begrepp
• AOI - Area of Interest beskriver den visuella miljön som är av intresse för undersökningen. (Definierat av forskaren, ej av del-tagaren)
• Fixering - Tillfälle då blicken fastnar vid en punkt.
• FD - Fixation Duration. Tiden i millisekunder blicken fixerar sig på en viss punkt på skärmen, fixationsvaraktighet på svenska. • Identifierare - namn på variabler, procedurer, typer etc.
• Metoder - metoder är en sorts procedurkontrollsflödesabstrak-tion i Java
2.1.2 Procedurer - abstraktion av kontrollflöde
Procedurell abstraktion eller procedurer som förkortning, är en mapp-ning från en uppsättmapp-ning inmatmapp-ningsargument till en uppsättmapp-ning ut-argument genom eventuell modifikation av indata. Uppsättningen in-argument eller ut-resultat eller båda må vara tomma [27]. Abstraktio-nen abstraherar bort irrelevanta detaljer men instansernas relevanta detaljer i abstraktionen måste alla överensstämma, men kan skiljas i de irrelevanta detaljerna [27]. Det finns två gynnsamma effekter av procedurer- Den första är lokalitet vilket betyder att implementatio-nen av en abstraktion kan läsas eller skrivas utan att behöva känna till implementationen utav andra procedurer. På så sätt kan flera per-soner självständigt jobba på olika delar av programmet utan att behö-va kunna implementationen av alla delar. En annan gynnsam effekt utav procedurer är modifierbarhet. Om implementeringen av en proce-dur förändras men inte dess specifikation (utdata, indata) så kommer förändringen inte ha någon påverkan på hur programmet fungerar [27]. Procedurer som kontrollflödesabstraktion är kallade metoder i Ja-va men kommer hänvisas till som procedurer i denna uppsats då pro-grammeringsspråket inte är det relevanta.
2.1.3 Mjukvaruunderhåll
Mjukvaruunderhåll är en viktig del av mjukvaruutveckling och defi-nieras som "[...] the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment"[15].
Under de senaste årtiondena har mjukvaruunderhåll rapporterats stå för majoriteten av mjukvarukostnader [3] där den relativa kostna-den representerar mellan 85-90% av kostna-den totala kostnakostna-den för mjukva-ran [12].
KAPITEL 2. BAKGRUND 5
2.1.4 Läsbarhet i litteratur
Under 1920-talet tog E. L Thorndike fram den första formeln för att beräkna hur svår en text var genom boken Teacher’s Word Book vilken kom ut år 1921. Han tog fram ett sätt att beräkna hur svår nivå en text hade beroende på hur frekvent ordet används i engelskan [9]. Denna bok lade grunden till nästan all forskning inom läsbarhet och sedan dess har ett flertal formler tagits fram för beräkna läsbarheten hos en text där författare såsom Rudolf Flesch, George Klare etc. som fick vida användning i journalism/forskning/juridik och industri. Läsbarhet är hur lätt det är att läsa vissa texter jämfört med andra och har helt med texten att göra. Läsbarhet är ofta förväxlat med läslighet vilket har att göra med layout och typsnitt och inte textens läsbarhet i sig [10].
Läsbarhet är definierat som “the ease of understanding or compre-hension due to the style of writing” av George Klare [24] medan Edgar Dale och Jeanna Chall definierar läsbarhet som “The sum total (inclu-ding all the interactions) of all those elements within a given piece of printed material that affect the success a group of readers have with it. The success is the extent to which they understand it, read it at an optimal speed, and find it interesting” [8]. Enligt Dubay är Dale-Chall läsbarhetsformlen den mest pålitliga med en korrelationskoeffi-cient på 0.92 på förståelse av texter mätt genom läsförståelsetest [9]. Dale-Challs formula använder sig av en lista med 3000 lätta ord där orden som inte är med i denna lista som svåra. [9] och på så sätt kan man få fram svårigheten av texten genom formeln:
xc50 = 0.1579x1+ 0.0496x2+ 3.6365 (2.1) • xc50= läsbarhetspoäng för en elev som kan svara korrekt på
hälf-ten av testfrågorna
• x1 = Dale poäng (relativt antal ord utanför listan av 3000 lätta ord)
• x2 = Genomsnittlig meningslängd 3.6365 (konstant)
• Genomsnittlig meningslängd (ASL) • Antal stavelser per ord (AWL) Där poängen räknas ut genom:
Score = 206.835 (1.015⇤ ASL) (84.6⇤ ASW ) (2.2) Det finns ett flertal andra formler som är i användning idag och grundtanken är densamma: användning av kortare meningar i genom-snitt med färre ord med många stavelser förenklar läsbarheten av tex-ten.
2.1.5 Läsbarhet av kod
Efter mjukvarukrashen under sent 1960-tal lades mycket tid på att ut-veckla nya verktyg för att förenkla utveckling av kod med hög kvali-tet [21]. Samtidigt som disciplinen datavetenskap utvecklades gjordes studier på komplexitet av kod både teoretiskt och experimentellt av bland annat Halstead [18] och Fitzsimmons and Love [14] [21]. Dessa studier grundades på längden av program men behandlade inte pro-grammeringsstil. Ett fåtal publikationer om programmeringsstil gjor-des [21]. Här var bland annat Roberts och McCracken och Weinberg pi-onjärer inom läsbarhet i mjukvarukonstruktion. [23]. Elshoff [11] stu-derade läsbarhet av 120 kommersiella program skrivna i PL/I från Ge-neral Motors och drog slutsatsen att läsbarhet av program inte kan mätas automatiskt men det existerar specifika attribut som påverkar läsbarheten av kod [21]. Han föreslog att följande instruktioner skulle följas för att öka läsbarheten av kod:
• Modularisera program
• Använda fler kommentarer och ge bättre namngivningar för att öka läsbarhet.
• Utnyttja en kontrollerad programmeringsmetod för att undvika programkomplexitet så att dataflöde och logik kan förstås enkla-re
KAPITEL 2. BAKGRUND 7
[23]. Weissman genomförde ett antal experimentella försök för att för-stå den psykologiska komplexiteten i program och fann att variabel-namn, programstruktur, kommentarer, kontrollflöde och styckeindel-ning hade stor påverkan på läsbarhet [21].
Buse och Weimer, inspirerade av läsbarhet i naturliga språk [23], undersökte konceptet av läsbarhet av kod och jämförde det med ko-dens kvalitet. De tog fram ett läsbarhetsmått med 80% effektivitet på att bedöma läsbarhet av kod, bättre än en genomsnittlig människas [5]. De fann att längden av identifierares namn är av liten betydelse för läs-barhet av kod men att långa namn, när ett kort namn skulle räckt, på-verkar läsbarhet negativt. De fann även att kommentarer ökar läsbar-het med 33%. Den största påverkan på läsbarläsbar-het av kod hade antalet identifierare per kodrad, vilket motsvarar läsbarhet av långa meningar i naturliga språk [5].
Binkley et al. studerade mer än 6 miljoner rader kod från applika-tioner med öppen källkod och studerade vikten av namngivningseti-kett på läsbarhet. De fann att namngivning med snake_case, (identifie-rare uppdelade med understreck) var mer läsbart jämfört med camel-Case (identifierare uppdelade med kapitalisering) i naturliga språk. Å andra sidan fann man att deltagare hade lättare att hitta identifierare med camelCase jämfört med snake_case med högre precision hos delta-gare oavsett erfarenhet. De fann även att deltadelta-gare tränade i camelCase kände igen identifierare i camelCase snabbare än de tränade i snake_case [2].
Följt av idén bakom FRES följde SRES: Software Readability Ea-se Score framtaget av Börstler et al. SRES tolkar programmets iden-tifierare och nyckelord som ord, satser som meningar och längd på ord som stavelser [4]. SRES mäts med dessa på samma sätt som FRES med genomsnittlig ordlängd (AWL) tillsammans med genomsnittlig meningslängd (ASL) och beräknas enligt följande formel:
2.1.6 Eye-tracking - hur fungerar det
I denna studie kommer en eye tracker från företaget Tobii användas. Denna skickar iväg infrarött ljus som reflekteras i användarens ögon varefter positionen av användarens blick kan beräknas. Ljuset färdas in i retinan och ljus reflekteras tillbaka vilket gör att pupillen skiner. Det uppstår även en reflektion i hornhinnan som visas som en liten men skarp glimma. Beroende på positioneringen av dessa två reflek-tioner kan eyetrackern beräkna vart användarens kollar [28].
2.1.7 Mätning av eye-tracking
Metrik som används vid bestämning av läsbarhet är främst fixationer (fixation) och blickvaraktighet (gaze durations) som används vid eye-tracking. Fixationer inträffar när ögonen är relativt stationära, dvs. in-om en viss spridning av en punkt (typiskt runt 2 graders spridning) med en minimal varaktighet av ca. 100-200 ms [20]. Dessa uppstår vanligtvis genom att ta in eller dechiffrera information. Fixationer kan även avslöja mängden bearbetning som krävs av ett visst objekt i blic-kens aktuella betraktningsområde [28]. Blickvaraktighet är istället den kumulativa tiden som en serie fixationer inträffar inom ett visst intres-seområde [20]. Mellan två fixationer inträffar såkallade saccades vilka är snabba ögonrörelser [28]. Även s.k scanpaths kan vara användbara vid analys av ögonrörelser. En scanpath beskriver en saccade-fixation-saccade sekvens. En optimal scanpath vid sökning av ett specifikt ob-jekt visas genom en rak linje till det önskade målet med relativt korta fixationer [16].
KAPITEL 2. BAKGRUND 9
2.1.8 Läsbarhet av kod med eye-tracking
Enligt Sharafi et al and Busjahn et al var pionjärerna för studier inom eye-tracking inom läsbarhet av kod Crosby och Stelovsky 1990. Dessa undersökte hur elever läste algoritmer i Pascal med en eye tracker [23]. De fann att man läste texter på naturliga språk på ett annorlunda sätt jämfört med kod [7]. De fann även att nybörjare spenderade mycket mer tid på att läsa kommentarer till skillnad från erfarna Pascalpro-grammerare vilka koncentrerade sig mer på områden med menings-full kod [7].
En grupp av forskare som deltog i en internationell workshop vars tema var ögonrörelser i programmering ur ett utbildningsperspektiv i Tyskland 2011, studerade två nybörjarprogrammerares ögonrörel-ser. Dessa programmerare deltog i en tre månaders lång Java-kurs vid Freie Universität i Berlin med sex lektioner [23]. Ögonrörelser var inspelade vid 3 tillfällen, en gång i början av utbildningen, en gång i mitten- och slutligen i slutet av utbildningen. Forskarna upptäckte att nybörjarna började med att läsa hela koden från start till slut flera gånger vilket var snarlikt med hur man läser texter av naturliga språk [23]. Vid kursens slut hade deltagarnas läsning av kod förändrats dras-tiskt. Istället för att läsa hela koden hoppade de istället mellan rader för att förstå koden i detalj [23].
2.1.9 Liknande undersökningar
Börster et al (2015) jämförde läsbarhet av kod mellan kod nedbruten i s.k chunks (där varje del endast hade ett syfte) jämfört med kod ut-an uppdelningar av monolitisk struktur (d.v.s all kod skedde i ett en-da block av sekventiella satser) och evaluerade därefter hur bra SRES gjorde ifrån sig jämfört med andra läsbarhetsformler. De fann att pro-gram med högre nivå av dekomposition hade bättre värden på läsbar-het för samtliga formler och att SRES var likvärdig om inte bättre på att evaluera läsbarhet jämfört med de andra formlerna [4].
Hög grad av dekomposition är också en viktig del för att hantera komplexitet i kod då det minskar den kognitiva belastningen för pro-grammerare ytterligare och har en positiv inverkan på underhåll av kod.
Kapitel 3
Metod
I detta kapitel diskuteras val av metodik, utrustning och utförande samt hur data kommer analyseras.
3.1 Forskningsmetodik
Forskning inom mjukvaruutveckling kan utföras genom tillämpning av fyra metodiker: vetenskaplig-, teknisk-, empiriskt och analytisk me-todik.
• I den vetenskapliga metodiken observerar forskare världen och föreslår en modell eller teori för att beskriva det studerade feno-menet med. De simulerar sedan modellen, mäter och analyserar den för att sedan validera hypotesen [23].
• I den tekniska metodiken studerar forskare istället befintliga lös-ningar som analyseras, utvecklas, mäts och evalueras [23]. • Den empiriska metodiken används när forskare inte kan
adres-sera problemet med naturlagar. Då föreslås en modell och en sta-tistisk metod utvecklas för att validera modellen [23].
• Slutligen, i den analytiska metodiken, förslår forskare en teori som sedan jämförs med andra empiriska observationer om möj-ligt [23].
I denna studie kommer en empirisk metodik användas då jag tän-ker studera deltagarnas ögonrörelser. Då jag ämnar jämföra relationen
mellan olika grupper av deltagare och skillnad mellan två variabler (proceduruppdelad/monolitisk kod) kommer ett kvantitativt forsk-ningsparadigm att användas för att nå ett svar till forskningsfrågan.
Det finns olika strategier för forskare att utföra en empirisk studie, bland dessa presenteras följande: undersökning, fallstudie och kon-trollerat experiment [23].
En undersökning används när forskare inte har möjlighet att kon-trollera utförandet av studien eller kan manipulera variablerna i studi-en. Då används ofta formulär eller intervjuer för att samla in kvalitativ eller kvantitativ data [23].
En fallstudie studerar tidigare fall och utvärderar dessa. Fallet be-höver vara en fristående enhet med tydlig avgränsning för att kunna studeras [13]
Ett kontrollerat experiment används för att undersöka en relation. Detta genom att manipulera en variabel medans de andra variabler-na hålls konstanta under experimentet. Resultatet är sedan avariabler-nalyserat utifrån variabelns påverkan [23].
I denna studie kommer en relation att undersökas och en oberoen-de variabel kommer att manipuleras unoberoen-der experimentet (ifall kooberoen-den är uppdelad i procedurer eller ej) och beroende variabler kommer mä-tas (fixation durations (FD), tid tagen att lösa uppgifterna och antal rätta svar). Därför kommer experimentet att vara ett kontrollerat ex-periment.
3.2 Utrustning
För att genomföra experimentet användes en Tobii eye-tracker tilsam-mans med spelmotorn Unity och Tobiis Unity SDK. Eye-trackern an-vändes för att ge en förståelse i hur deltagarna läser kod och ifall det förekom några avvikelser i hur de läste kodsegmenten. Flera faktorer som skulle kunnat vara avgörande i experimentet hade kunnat gå för-lorade ifall deltagarna endast skulle bedömts efter hur snabbt de löst problemen och hur bra de löst dessa. Därför var det viktigt att se exakt hur deltagarna läste koden för att kunna se vilka delar av koden som varit signifikanta.
Unity användes då Tobii erbjöd Unity SDK vilket gjorde det möjligt att skräddarsy programmet till experimentet.
KAPITEL 3. METOD 13
med Tobiis Gaze Overlay användes för att informera om vart delta-garnas blick var i koden under hela kodläsningen och hur deras blick rörde sig. Detta användes främst för att kunna identifiera ifall eye-trackingen hade misslyckas och för att lätt upptäcka ifall det skett någ-ra avbrott i kodläsningen, men även för att kunna identifienåg-ra mönster i hur deltagarna läste koden.
Figur 3.1: Kodsegment med gaze overlay, detta visas endast för rese-archern och inte för deltagarna
3.3 Datainsamling
Jag valde att göra variabelnamnen så intetsägande som möjligt för att inte deltagarna skulle kunna känna igen de olika kodsegmenten, då två av kodsegmentena i själva verket hade samma innebörd. Det ända som skiljde dessa kodsegment från varandra var huruvida de var pro-ceduruppdelade eller ej. Jag hade även ändrat värdena på variablerna så att inte deltagarna ska kunna gissa sig till att svaret är samma som i föregående kodsegment. Kodsegmenten som hörde till varandra var dessutom placerade i oordning så att deltagarna skulle ha ännu svå-rare att komma ihåg kodsegmenten som hade med varandra att göra. Kodsegmenten var inte syntaxmarkerade för förhindra att någon av kodsegmenten hade en fördel i huruvida läsliga de var [33]. Koden hade genomgående samma font med vit textfärg och mörkgrå bak-grund. Den mörka bakgrunden var speciellt viktig då eye-trackingen fungerade sämre med en vit bakgrund eftersom det skarpa ljuset re-flekterades i ögonen och störde eye-trackerns förmåga att identifiera blickens rörelse.
När kodsegmenten lästes spelade eye-trackern in blickens position och hur länge de fixerade blicken på en viss punkt, deras sk. fixation duration (FDs). Fastnade en blick på en viss punkt längre än 150 ms sparades dessa som en FD.
Dessa FDs sparades på fil med respektive position i x- och y-led. De sparades även i kodsegmenten de läste utan att deltagaren ser dem. När deltagaren sedan klickade för att gå vidare till nästa experiment sparades det nuvarande kodsegmentet som en bild med FDs utritade ovanpå kodsegmentet tillsammans med deltagarens svar på utdata (se Bilaga).
Experimentet avslutades med att låta deltagarna svara på ett for-mulär om hur lång erfarenhet de hade av programmering samt Java i synnerhet och vilken nivå de tyckte de var på när det gäller Java. Med hjälp av formuläret tog jag även reda på ifall deltagarna hade något problem med synen (t.ex. glasögon eller linser) eller med att läsa då det kunde påverka resultaten av eye-trackingen.
3.4 Layout av AOI
KAPITEL 3. METOD 15
och i indatafältet skrev deltagaren vad de tyckte kodsegmentet skul-le ge för utdata. Bredvid indatafältet fanns en knapp som vid klick tog deltagaren till nästa uppgift och datan sparades för varje avslutad uppgift. Utdata i form av bild ser ut som figur 3.3.
Figur 3.3: Utdata från kodsekvens som bild från experimentet
3.5 Kodsegment
KAPITEL 3. METOD 17
KAPITEL 3. METOD 19
3.6 Analys av data
Resultat och Analys
Nedan kommer resultaten av formuläret och eye-trackingen presente-ras i samband med analys utav denna.
Majoriteten av deltagare ansåg sig välorienterade med Java (Figur 4.1) och samtliga deltagare hade tidigare erfarenhet av kodning i annat språk.
Figur 4.1: Svaren på frågan ang. hur välorienterade deltagarna känner sig med Java
Andelen korrekta svar på den proceduruppdelade versionen jäm-fört med den monolitiska var betydligt lägre i uppgift två, men där-emot högre i uppgift ett och lika i uppgift tre. Programmerare som ansåg sig vara professionella hade alla rätt på uppgifterna medans de andra hade signifikant lägre antal rätt svar.
KAPITEL 4. RESULTAT OCH ANALYS 21
Figur 4.2: Andel korrekta svar på den monolitiska respektive proce-duruppdelade versionen av samma uppgift
Figur 4.3: Tiden tagen i minuter att lösa varje problem per deltagare. Staplarna förekommer i samma ordning som teckenförklaringen där monolit11 (monolitisk) och prodedur1 (procedurell) är respektive svar på samma uppgift.
KAPITEL 4. RESULTAT OCH ANALYS 23
KAPITEL 4. RESULTAT OCH ANALYS 25
Ett intressant mönster uppstod hos flera av de mer erfarna delta-garna men även hos en nybörjare vilket bestod av att de läste en bit av första kodraden men hoppade snabbt till en annan kodrad (rad x) för att sedan hoppa tillbaka till den initiala kodraden i väldigt snabb succession i en s.k scan-path (se Figur 4.6).
Det verkar som om de bara ger kodraden de hoppar till en snabb överblick medans de läser rad 1 ordentligt då de är få fixationer med väldigt kort varaktighet på raden de hoppar till. Dessa mönster upp-kom vare sig de läste monolitisk eller proceduruppdelad kod och del-tagarna hade alla fyra eller fler rätt.
Figur 4.6: Exempel på hur erfarna programmerare läser kod. Rad x betecknar godtycklig rad.
Värt att nämna är hur kodsegment uppdelade i procedurer genere-rar kortare FDs jämfört med monolitisk kod (se Figur 4.5). Den kortare genomsnittliga fixationsvaraktigheten i proceduruppdelad kod jäm-fört med monolitisk skulle kunna förklaras genom att deltagaren mås-te hoppa i koden till procedurerna vilket de inmås-te behöver i monolitisk kod och därför har proceduruppdelad kod fler fixationspunkter. pro-ceduruppdelad kod har även lägre fixationsvaraktighet på majoriteten av fixationerna jämfört med vad monolitisk kod har.
Detta mönster skiljer sig dock från vanliga hopp till procedurer där detta sker långsammare Man kan även finna att monolitisk kod har många fler punkter med signifikant längre fixationsvaraktighet än vad proceduruppdelad kod har.
Figur 4.7: Exempel på hur sekventiell läsning sker, samma mönster uppkommer vid läsning av litteratur
Denna deltagare hade även signifikant fler fixationspunkter i den proceduruppdelad koden jämfört med den monolitiska.
KAPITEL 4. RESULTAT OCH ANALYS 27
Figur 4.8: FDs > 150 ms i exempel 3 (uppdelad i procedurer) för delta-gare 3, professionell.
Diskussion
I detta kapitel kommer resultaten att diskuteras samt felkällor.
Från resultatet av experimenten visar det sig ta längre tid att läsa kod som är uppdelad i procedurer jämfört med monolitisk kod för ny-börjare. Detta kan bero på att de inte är vana vid att använda sig utav procedurabstraktionen ännu. Denna skillnad verkar dock minska ju mer erfarna de blir med språket då de erfarna löser proceduruppde-lad kod snabbare eller lika snabbt som monolitisk kod.
Den enda deltagaren som läste koden sekventiellt visade sig dess-utom ha mycket lättare för sig att läsa monolitisk kod jämfört med pro-ceduruppdelad kod. Detta berodde sannolikt på att hen läste igenom koden helt och hållet på ett sekventiellt sätt för att sen hoppa mellan block av kod. Men då detta endast inträffade hos en av de tio delta-garna är det svårt att dra någon generell slutsats utan fler experiment måste göras med folk som är helt nya programmerare (d.v.s har inte erfarenhet av något annat programmeringsspråk över huvud taget).
Att läsbarheten ökade med proceduruppdelning hos erfarna pro-grammerare stämmer överens med studien Beauty and the Beast. Dessa tog dock inte erfarenhetsnivån hos programmerarna i beaktande vil-ket jag gjorde. Man kan därför anta att deras formel SRES, endast kan bestämma läsbarhet av en text utifrån perspektivet att den som läser koden kommer vara en erfaren programmerare.
5.1 Felkällor
Flera variabler kan ha påverkat experimentet- först och främst var de valda deltagarna väldigt brett skilda. Vissa hade lång erfarenhet av
KAPITEL 5. DISKUSSION 29
andra språk men var ändå nybörjare i Java. Det var troligtvis detta som gjorde att majoriteten av deltagarna inte läste koden sekventiellt. Det är också svårt att fastställa en generell slutsats för procedurer mot monolitisk kod då deltagarna är så få utan slutsatsen kan bara göras för vad jag funnit i detta experiment. Fler experiment måste göras för att fastställa detta med säkerhet då osäkerheten är stor.
En deltagare nämnde även att de fäste blicken vid en specifik punkt då hen tänkte, vilket många antagligen gör, och därför kan det före-komma felaktiga fixationspunkter. Totalt tappades eye-trackingen da-tainsamling under en del av testare två och och testare 8:as uppgifter i exempel 1, exempel två respektive exempel två och tre vilket påver-kade resultaten för den genomsnittliga fixationsvaraktigheten per pro-blem och figuren med antalet FDs. Detta berodde med störst sannolik-het på att båda deltagare bar glasögon.
Vidare råkade testare 7 klicka sig förbi ett av experimenten och tes-tare 9 missade att det var flera loopar i exemplen med procedurer. Det är också svårt att tyda ifall testarna gissar på svaren. I ett fall kan man se att deltagaren inte tittar på en rad där det förekommer en utskrift innan denna svarar på kodsekvensen vilket kan betyda att deltagaren gissar, men det är svårt att avgöra.
Avslutning
Från resultaten kan man konstatera att proceduruppdelad kod är svå-rare för nybörjare att tyda jämfört med erfarna programmesvå-rare vilka till och med löste proceduruppdelad kod snabbare än monolitisk.
Man kan därför konstatera att kontrollflödesabstraktioner i form av procedurer gör det lättare för programmerare att läsa kod men det krävs tid och vana för att ta del av de gynnsamma effekterna utav dem. Därför bör mycket tid läggas på att lära nybörjare förstå hur man läser proceduruppdelad kod vid ett tidigt stadie för att dessa ska kunna dra nytta av t.ex. chunking och på så sätt läsa kod snabbare och effektivare. Det skulle vara intressant att testa läsbarhet av kod ytterligare ge-nom att låta erfarna programmerare hitta buggar i kod mellan monoli-tiskt uppbyggda program och program uppdelade i procedurer och på så sätt kunna anknyta slutsatsen närmare till underhåll av mjukvara.
Det skulle även vara intressant att undersöka ögonrörelser hos er-farna programmerare och ifall detta skulle kunna användas som test vid arbetsintervjuer eller som grund för att utbilda nya programmera-re i hur man ska se på kod för effektiv läsning.
Då denna studie var begränsad till en relativt kort tidsram skulle det vara intressant att föra ytterligare studier med samma metodik för att se om dessa resultat håller för en större deltagargrupp. Det skulle även vara intressant att studera ytterligare hur man kan öka nybörja-res förståelse utav proceduruppdelning så att dessa snabbt kan ta del av dess fördelar såsom chunking och ifall det kan inkorporeras i ut-bildningen inom programmering.
Litteratur
[1] Krishan K Aggarwal, Yogesh Singh och Jitender Kumar Chhab-ra. “An integrated measure of software maintainability”. I: Re-liability and maintainability symposium, 2002. Proceedings. Annual. IEEE. 2002, s. 235–241.
[2] Dave Binkley m. fl. “To camelcase or under_score”. I: Program Comprehension, 2009. ICPC’09. IEEE 17th International Conference on. IEEE. 2009, s. 158–167.
[3] Barry W Boehm. “Software engineering economics”. I: IEEE transactions on Software Engineering 1 (1984), s. 4–21.
[4] Jürgen Börstler, Michael E Caspersen och Marie Nordström. “Beauty and the Beast: on the readability of object-oriented ex-ample programs”. I: Software quality journal 24.2 (2016), s. 231– 246.
[5] Raymond PL Buse och Westley R Weimer. “A metric for software readability”. I: Proceedings of the 2008 international symposium on Software testing and analysis. ACM. 2008, s. 121–130.
[6] SN Cant, D Ross Jeffery och Brian Henderson-Sellers. “A con-ceptual model of cognitive complexity of elements of the pro-gramming process”. I: Information and Software Technology 37.7 (1995), s. 351–362.
[7] Martha E Crosby och Jan Stelovsky. “How do we read algo-rithms? A case study”. I: Computer 23.1 (1990), s. 25–35.
[8] Edgar Dale och Jeanne S Chall. “The concept of readability”. I: Elementary English 26.1 (1949), s. 19–26.
[9] William H DuBay. “The Classic Readability Studies.” I: Online Submission (2007).
[10] William H DuBay. “The Principles of Readability.” I: Online Sub-mission (2004).
[11] James L. Elshoff. “An analysis of some commercial PL/I pro-grams”. I: IEEE Transactions on Software Engineering 2 (1976), s. 113–120.
[12] Len Erlikh. “Leveraging legacy system dollars for e-business”. I: IT professional 2.3 (2000), s. 17–23.
[13] Fallstudier. Febr. 2016. URL: https : / / forskningsstrategier . wordpress . com / fallstudier/.
[14] Ann Fitzsimmons och Tom Love. “A review and evaluation of software science”. I: ACM Computing Surveys (CSUR) 10.1 (1978), s. 3–18.
[15] John R Foster. “Cost factors in software maintenance.” Diss. Dur-ham University, 1993.
[16] Joseph H Goldberg och Xerxes P Kotval. “Computer interface evaluation using eye movements: methods and constructs”. I: International Journal of Industrial Ergonomics 24.6 (1999), s. 631– 645.
[17] Joseph H Goldberg m. fl. “Eye tracking in web search tasks: de-sign implications”. I: Proceedings of the 2002 symposium on Eye tracking research & applications. ACM. 2002, s. 51–58.
[18] Maurice H. Halstead. “Advances in software science”. I: Advan-ces in Computers. Vol. 18. Elsevier, 1979, s. 119–172.
[19] Michael Hansen, Robert L Goldstone och Andrew Lumsdaine. “What makes code hard to understand?” I: arXiv preprint arX-iv:1304.5257 (2013).
[20] Robert JK Jacob och Keith S Karn. “Eye tracking in human-computer interaction and usability research: Ready to deliver the promises”. I: The mind’s eye. Elsevier, 2003, s. 573–605.
[21] Anker Helms Jørgensen. “A methodology for measuring the re-adability and modifiability of computer programs”. I: BIT Nu-merical Mathematics 20.4 (1980), s. 393–405.
LITTERATUR 33
[23] Pezhman Kasraee och Chong Lin. Readability of Method Chains: A Controlled Experiment with Eye Tracking Approach. 2016.
[24] George Roger Klare m. fl. “Measurement of readability”. I: (1963).
[25] Dator Kunskap. Underhållsfasen i programvarans livscykel. URL:
http : / / www . dator . xyz / Felsokning / pc - support / 188554.html(hämtad 2018-05-08).
[26] Bennet P Lientz, E. Burton Swanson och Gail E Tompkins. “Cha-racteristics of application software maintenance”. I: Communica-tions of the ACM 21.6 (1978), s. 466–471.
[27] Barbara Liskov, John Guttag m. fl. Abstraction and specification in program development. Vol. 180. MIT press Cambridge, 1986. [28] A Poole och LJ Ball. “Eye tracking in human-computer
interac-tion and usability research: current status and future prospects, 2005”. I: United Kingdom: Psychology Department, Lancaster Uni-versity ().
[29] Alex Poole, Linden J Ball och Peter Phillips. “In search of sa-lience: A response-time and eye-movement analysis of book-mark recognition”. I: People and computers XVIII—Design for life. Springer, 2005, s. 363–378.
[30] John Sonmez. What Makes Readable Code: Not What You Think. 2013. URL: https : / / simpleprogrammer . com / what
-makes-code-readable-not-what-you-think/(hämtad 2018-02-20).
[31] Thomas A Standish. “An essay on software reuse”. I: IEEE Trans-actions on Software Engineering 5 (1984), s. 494–497.
[32] Jeff Sutherland. “Business objects in corporate information systems”. I: ACM Computing Surveys (CSUR) 27.2 (1995), s. 274– 276.
Extra Material som Bilaga
Figur A.1: Svaren på frågan ang. hur lång erfarenhet deltagarna hade av att koda generellt sett
BILAGA A. EXTRA MATERIAL SOM BILAGA 35
Figur A.2: Svaren på frågan ang. hur lång erfarenhet deltagarna hade av Java i synnerhet
