Lättviktig kodgranskning

Utifrån de resultat som presenteras av Steve McConnell [65] så framgår att lättviktig gransk- ning inte hittar lika mycket fel som en formell inspektion. Enligt McConnell [65] så var en blandning av flera olika typer av granskning inte en ovanlig syn, och med tanke på hur ”bil- lig” lättviktig granskning är så är det inte orimligt antagande att de flesta projekt använder sig av någon form av lättviktig kodgranskning.

Även Jim Bird [66] berör ämnet, och trycker på att både stora och små team kan använda sig av verktygsbaserad granskning, en metod som faller in under kategorin lättviktig gransk- ning.

Då lättviktiga granskningar inte är särskilt tidskrävande kan man argumentera för att det alltid finns någon typ av lättviktig granskning som passar in på ett projekt oberoende av storlek. Till mindre projekt, både till längd i tid och till storlek i antal personer, kan det räcka med att man ber en medarbetare ta en titt på en bit kod man vill få synpunkter på; detta räknas som en lättviktig granskning. Till större projekt, sett till storlek i antal personer, kan det vara vettigt att använda sig av en verktygsbaserad granskningsmetod som Bird nämner. Detta då det skulle kunna bli väldigt rörigt att sköta och följa upp granskningar genom t.ex. epost om ett projekt består av till exempel 50 personer jämfört med om projektet skulle bestå av 3 personer.

D.6.4

Källkritik

Under denna undersökning har ett antal källor använts, både för att förklara bakomliggan- de teori och för att erhålla tidigare resultat. Dessa källors innehåll och ursprung diskuteras nedan.

Advances in Software Inspections I denna artikel skriven av Michael Fagan beskrivs effek-

ten av att ha implementerat Fagan inspection på IBM. Effekten som beskrivs i denna artikel är baserad på undersökningar på IBM, där Michael Fagan arbetade när artikeln skrevs. Som namnet antyder så är Michael Fagan skaparen av Fagan inspection, en formell gransknings- metod. Artikeln är en del av boken Pioneers and Their Contributions to Software Engineering [67], och artikeln har blivit citerad mer än 900 gånger enligt Google Scholar.

Design and Code Inspections to Reduce Errors in Program Development Denna artikel

är skriven av Michael Fagan, och i den så beskrivs Fagan inspection väldigt detaljerat. Även mindre undersökningar presenteras, som är kopplade till framtagandet av denna gransk- ningsmetod. Under denna undersökning har den här artikeln använts för att förklara hur Fagan inspection fungerar, och då denna artikel är skriven av granskningsprocessens skapa- re verkade den lämplig. Lämpligheten kan styrkas av att artikeln blivit citerad mer än 2000 gånger enligt Google Scholar.

Code Complete, Second Edition Denna bok är skriven av Steven McConnell, och publi-

cerad Microsoft. McConnell prisas högt [68] som mjukvaruutvecklare och projektledare, och mellan åren 1998 och 2002 arbetade han som huvudredaktör på IEEE [69]. Boken är väldigt genomgående, och de tidigare resultat som använts från denna bok är bara en bråkdel av dess innehåll. Även denna bok har refererats till flitigt; enligt Google Scholar har den citerats mer än 1500 gånger.

Not doing Code Reviews? What’s your excuse? Detta blogginlägg är skrivet av Jim Bird.

I sin blogg skriver Bird att han är en projektledare och CTO, med mer än 20 års erfarenhet i industrin. Då Bird skriver mycket utifrån erfarenhet, så får man ha i åtanke att det kan bli mer subjektiv information jämfört med mer utförliga undersökningar. Med tanke på Birds långa erfarenhet i industrin så har hans erfarenheter ett stort värde; och det var en utmanande upp- gift att hitta källor som diskuterar både formell kodgranskning och lättviktig kodgranskning. Jim Bird gör just detta, och därför har den använts i denna undersökning.

D.7. Slutsatser

D.7

Slutsatser

Kodgranskningen som utförts i detta projekt visade sig ha en överlag positiv effekt med av- seende på kvalitet. Utifrån de undersökningar som utförts så visar sig lättviktig granskning vara en billig granskningsmetod som har en positiv effekt på kodkvalitet. Denna kategori av granskning är så flexibel att den passar in på projekt av olika storlekar. Formell granskning såsom Fagan inspection hittar en väldigt stor andel fel i kod, men är istället mycket dyrare att utföra. Denna typ av granskning kanske istället beror på vilka kvalitetskrav som ställs på produkten.

1. Vilka effekter hade kodgranskningen i det här projektet? Granskningen som utfördes

genom Trello hittade defekter i nästan 20% av aktiviteterna slutfördes under projektets gång. 6 av 7 projektmedlemmar ansåg att granskningen var givande; alltså att färre buggar och/el- ler designmissar påträffades under granskningen.

2. Till vilken storlek av projekt lämpar sig formell kodgranskning? Det erhölls inte till-

räckligt med underlag för att avgöra vilken storlek av projekt som formell kodgranskning lämpar sig till. Vad det däremot finns underlag för är den formella kodgranskningens in- effektivitet; den hittar väldigt många fel till en stor kostnad. Om ett projekt ställer väldigt höga krav på koden med avseende på kvalitet så kan det då vara av intresse att titta på en formell kodgranskning, men det är inget som den här undersökningen har behandlat. Det kan däremot vara av intresse att få in inslag av en formell kodgranskning i ett projekt; oav- sett storlek. Ju större ett projekt är till antal personer och tillgänglig tid, desto mer inslag av formell kodgranskning finns det plats att experimentera med.

3. Till vilken storlek av projekt lämpar sig lättviktig kodgranskning? Lättviktig kod-

granskning är en väldigt bred kategori av granskningsmetoder, då den innehåller parpro- grammering, verktygsbaserad granskning, och i princip allting som inte är en variation på Fagan inspection. Detta leder till att det i princip alltid finns en lättviktig granskningsmetod som passar in på ett projekt, oavsett storlek. Mycket av detta är tack vare dess effektivitet; dessa granskningsmetoder hittar inte lika många fel som en formell kodgranskning men sam- tidigt så är den mycket billigare att utföra.

E

Metoder för hinkpackning, ett

NP-svårt problem av Emil Luusua

E.1

Introduktion

Givet en mängd av n objekt med vikterna{w1, ..., wn}, packa dessa i hinkar med en fixerad

kapacitet c på ett sådant sätt att antalet använda hinkar minimeras med villkoret att ingen hinks viktsumma överskrider c. Enklare uttryckt, packa objekten i så få hinkar som de kan få plats i.

Det ovan beskrivna problemet benämns som hinkpackningsproblemet, förkortat BPP för det engelska begreppet Bin Packing Problem. Trots att det vid en första anblick kan verka simpelt är det ett av de mest studerade problemen inom optimeringsläran [70], vilket till stor del beror på att det är ett av de tidigaste att visas vara NP-svårt [71]. Ännu en bidragan- de faktor till det stora intresset för problemet är dess frekventa förekommande i industriella sammanhang, såsom att minimera spill vid användning av råmaterial eller packning av ett lagringsutrymme [72]. Problemets NP-svårighet antyder att en effektiv algoritm för att lösa det till optimalitet inte existerar. I värsta fall behöver samtliga lösningsalternativ undersö- kas, vilket inte är praktiskt genomförbart för den storlek av problem som dyker upp i många tillämpningar. Därför används ofta heuristiker för att ta fram en bra, men sällan optimal, lös- ning inom en rimlig tidsram. Mycket forskning har dock gjorts på metoder för att kunna ta fram en optimal lösning även i stora probleminstanser genom att på ett intelligent sätt be- gränsa delmängden lösningar som behöver undersökas, detta individuella bidrag behandlar dessa.

E.1.1

Syfte

Syftet med detta bidrag var att undersöka huruvida en alternativ lösningsmetod för optime- ringsproblemet i det utförda projektet hade kunnat appliceras av projektgruppen och därige- nom skapa ytterligare värde för kunden.

E.1.2

Frågeställningar

De frågeställningar som behandlas i detta individuella bidrag presenteras nedan.

1. Vilka typer av metoder finns för att lösa BPP och hur fungerar dessa? Eftersom pro-

blemet är väl efterforskat har stor en mängd olika lösningsmetoder tagits fram, bidragets omfattning är inte tillräckligt stor för att behandla samtliga utan ett urval har gjorts.

2. Hade någon av de undersökta metoderna kunnat appliceras i det utförda projektet?

Projektgruppen hade ingen tidigare erfarenhet av optimeringslära utöver en grundkurs i kombinatorisk optimering. Det är därför osäkert om tillräcklig kunskap fanns tillgänglig för att kunna applicera någon av de undersökta metoderna inom projektets tidsbudget.

3. Hur jämför sig de undersökta metoderna mot varandra? Jämförelsen avser metodernas

prestanda och förmåga att kunna ta fram en optimal lösning inom en begränsad tidsram.

E.2

Bakgrund

Ett av de planeringsproblem Ionbond står inför varje gång deras beläggningskammare ska köras är hur tallrikar ska monteras på satelliter för att så få som möjligt ska behöva användas. Detta kan modelleras som ett BPP genom att hinkar representeras av satelliter och tallrikar- na är objekten som ska packas, där kapacitet och vikt motsvaras av satelliternas respektive tallrikarnas höjd.

I korthet var projektgruppens lösning att först beräkna en undre gräns för hur bra en lösning möjligtvis kan bli och därefter snabbt finna en tillåten lösning genom en simpel heu- ristik. Om den funna lösningen är lika bra som den undre gränsen är den också optimal, vilket vid testning observerats inträffa i en majoritet av fallen. I övriga fall används biblioteket oj! Algorithms, benämnt ojAlgo, som har stöd för att definiera och lösa allmänna heltalsproblem med hjälp av en färdig problemlösare [18]. Denna metod valdes på grund av tidsbrist i pro- jektets utvecklingsfas vilket gjorde en färdig lösning väl lämpad samt att bibliotekets licensie- ring tillåter den att användas utan kostnad. Problemlösaren är dock tyvärr väldigt ineffektiv eftersom den inte tar hänsyn till problemets struktur. I ett krav har Ionbond specificerat att optimeringen ska ske på under 60 sekunder och i många fall misslyckas problemlösaren pre- stera bättre än heuristiken under denna tidsbegränsning. Av denna anledning är det önskvärt att undersöka värdet i alternativa metoder.

E.3

Teori

Nedan presenteras teori från optimeringsläran som nyttjas av de metoder som beskrivs i avsnitt E.5.1.

E.3.1

Trädsökning

Trädsökning är det överlägset vanligaste tillvägagångssättet för att lösa stora instanser av NP-svåra problem inom kombinatorisk optimering [73]. Det fungerar genom att efterhand bygga upp en trädstruktur av lösningsmängder och systematiskt genomsöka denna. Roten innehåller då den totala lösningsmängden och trädet byggs därifrån upp rekursivt genom att i varje nod ta ett beslut för lösningens utseende och skapa en gren för varje möjligt val i beslu- tet, vilket resulterar i disjunkta lösningsmängder. Genom att spara den bästa funna lösningen och beräkna undre gränser för målfunktionsvärdet i varje skapad nod kapas grenar som inte kan förbättra den redan funna lösningen. På så vis undviks en fullständig uppräkning av alla möjliga lösningar och algoritmens tidseffektivitet ökar avsevärt. [19]

E.4. Metod

Detaljer för hur förgreningen och kapningen sker är problemspecifika. Väsentligt olika strategier kan också användas för lösning av samma problem, vilket gör att två trädsöknings- metoder kan behöva undersöka ett väldigt varierande antal noder och ta olika lång tid för undersökning av varje nod.

E.3.2

Dominanskriteriet

Givet två mängder objekt A och B, dominerar A mängden B om en packning av B i en hink aldrig kan ge en bättre lösning än om A packats i dess ställe. I praktiken innebär det att om flera olika sätt att packa en hink undersöks behöver endast packningar som ej domineras av någon annan beaktas. Huruvida en mängd domineras av en annan kan avgöras genom kon- troll av dominanskriteriet som lyder: om objekten i B kan delas upp i delmängder B1, ..., Bi

på ett sådant sätt att de kan matchas till ett objekt i A med större vikt än delmängdens sum- merade vikt, så domineras B av A. Ett exempel på detta är mängderna A= {40, 30, 20}och B= {25, 15, 15, 10, 10, 5}. Genom att dela upp B i{25},{15, 15, 10}och{10, 5}fås

40≥15+15+10 30≥25

20≥10+5 vilket ger att B domineras av A. [74]

E.3.3

Kolumngenerering

Kolumngenerering är en metod för att lösa stora instanser av linjära optimeringsproblem. De stora mängder av variabler i sådana kan vara svåra att hantera, kolumngenerering löser det- ta genom att dela upp problemet i ett master- och subproblem. I masterproblemet övervägs endast en liten delmängd av variablerna för att lösa det ursprungliga problemet, vilket görs genom att använda Simplexmetoden. Efter att detta lösts används den duala lösningen för att formulera subproblemet, vilket är ett nytt optimeringsproblem för att hitta den variabel som har mest negativ reducerad kostnad. Enklare sagt är subproblemet att hitta den variabel som skulle gett bäst förbättring om den övervägts i masterproblemet. De två problemen lö- ses därefter igen, nu med en ny variabel i masterproblemet. Processen upprepas iterativt tills ingen variabel med negativ reducerande kostnad existerar, i vilket fall lösningen till master- problemet även är en optimal lösning till det ursprungliga problemet. [75]

Namnet kolumngenerering kommer från att varje gång en variabel introduceras i master- problemet genereras en ny kolumn i Simplextablån. Metodens effektivitet kommer av att de flesta kolumnerna med stor sannolikhet endast innehåller nollor i den optimala lösningen för det ursprungliga problemet, vilket betyder att de aldrig genereras.

E.4

Metod

För att hitta information om olika typer av lösningsmetoder utfördes en litteraturstudie ut- gående från vetenskapliga artiklar. Material hittades genom sökning i LiU:s bibliotek efter termerna Bin Packing och Optimal Bin Packing med filtrering för tidskrifter som använder referentgranskning, samt genom den engelskspråkiga Wikipediasidan för BPP där ett antal resurser finns refererade i avsnittet om exakta algoritmer [76]. Genom de artiklar som fun- nits på detta sätt studerades sedan de källor som refererats till för att kunna använda de ursprungliga publikationer där lösningsmetoderna först presenterats.

För att testa metodernas applicerbarhet på det utförda projektet valdes en av de undersök- ta lösningsmetoderna att implementeras i det program projektgruppen utvecklat. Därefter jämfördes denna med projektets föregående lösning, en proprietär problemlösare samt en al- goritm som i detta bidrag benämns BCP [77], vilken hämtats från kodsamlingen BPPLIB [70]. Jämförelsen gjordes genom prestandatest vars utförande detaljeras nedan.

E.4.1

Prestandatestning

Prestandatesterna gjordes för tio icke-triviala testfall av varierande storlek. Med icke-triviala avses fall där den undre gränsen och heuristiska lösningen inte är lika för projektgruppens lösning. Testfallen ämnade att spegla Ionbonds användningsfall genom att verkliga tallriks- och satellithöjder samt en tidsbegränsning på 60 sekunder användes. På grund av tidsbe- gränsningen noterades utöver använd tid även antalet använda hinkar i den framtagna lös- ningen, trots att alla metoderna är gjorda för att leverera en optimal lösning.

Koden för BCP inkluderar stöd för testning vilken har nyttjats för att köra testfallen. Övri- ga metoder har testats tillsammans på JVM genom JUnit, ett ramverk för enhetstestning [15]. Varje testfall skrevs som ett separat enhetstest, i vilka alla metoderna testades efter varand- ra. Samtliga tester kördes därefter tillsammans som en gemensam testsvit utan att JVM:n startades om, vilket betyder att adaptiv optimering som JVM:en gör under exekveringstid skulle kunna ha en signifikant inverkan på testresultaten [57]. För att ändå uppnå tillförlitli- ga testresultat gjordes åtgärder för att minimera denna inverkan. Ett extra testfall kördes före de övriga med syfte att värma upp JVM:n och hela testsviten kördes i tre iterationer där både testfallens och metodernas ordning varierades. Samtliga test kördes på ett Linux Mint 18.2 system utrustat med dubbelkärniga Intel Core M-5Y10c CPU 0.80 GHz och 8 GB ramminne.

E.5

Resultat

Nedan presenteras det resultat som uppnåtts genom litteraturstudien, den algoritm som im- plementerats samt utförda prestandatest.