Code review is a recurring activity at software companies where the source code, orparts of it, undergoes an inspection where the aim is to detect possible errors beforethe code is released for production. A variation of code review that is common today iscalled modern code review and is more lightweight practise than formal code review. Inmodern code review, the developers participate and continuously revise their colleagues’code.At a financial technology company in Stockholm, modern code review is applied. Thecompany has expressed a need to implement a tool that can facilitate the code reviewprocess. One suggestion from the company was to implement high-level conceptual codereview (HCCR), an idea of a tool where code changes are sorted automatically intodifferent commits with a specific message.In order to implement the tool, HCCR needs to be defined and concretised since it haspreviously existed solely as an idea. As a first step of the project, developers’ view ofwhat information is desirable in a commit needed to be examined. The project addressedthe following research questions: What information is desirable and needed by the developers of a medium-sizedcompany, to help them do code reviews in a pull-based environment?– What should the information consist of?– How should the information be presented?To answer these questions, interviews were conducted with software developers at thecompany, together with observations where the developers had to try out a first iterationof HCCR. The first iteration was developed using the company’s guidelines on howdevelopers contribute to code changes together with our company supervisor’s viewson how the tool can work. The interviews were recorded and transcribed, whereafteriia thematic analysis was applied. From the analysis, 13 concepts emerged, which weredivided into five categories. The developers wanted the commits to be atomic, compilableand testable in order to facilitate debugging. The developers also expressed a need toget clear information about both pull-requests (PRs) and commit messages. In theinterviews, a theme emerged that the messages should consist of: what has changed andwhy it has changed. Differences were also observed in the code review process as differentdevelopers use different strategies when reviewing code.Based on the information that emerged from the interviews and observations along withprevious research, a second iteration of HCCR was prepared. The report concludes bydiscussing possible implementations of the tool. / Kodgranskning är en vanligt förekommande aktivitet hos mjukvaruföretag där källkoden,eller delar av den, genomgår en granskning för att upptäcka möjliga fel innan kodensläpps till produktion. En variation av kodgranskning som är vanlig idag kallas modernkodgranskning och är en mindre formell kodgranskning där utvecklarna själva är medoch kontinuerligt reviderar sina kollegors kod.Ett finansiellt teknikbolag i Stockholm tillämpar modern kodgranskning. Företagethar uttryckt ett behov av att implementera ett verktyg som kan underlättakodgranskningsprocessen. Ett förslag från företaget var att implementera HCCR, enidé om ett verktyg där kodändringar automatiskt sorteras till olika, så kallade, commits1med ett specifikt meddelande.För att implementera verktyget behöver HCCR definieras och konkretiseras. Som ettförsta steg i projektet behövde vi undersöka utvecklarnas önskvärda information av huren commit bör utformas. Projektet behandlar följande forskningsfrågor: Vilken information är önskvärd och behövs av utvecklarna på ett medelstort företag,för att hjälpa dem att göra kodgranskningar i en pull-based miljö?– Vad ska informationen bestå av?– Hur skall informationen presenteras?För att svara på frågorna gjordes intervjuer med mjukvaruutvecklarna på företagettillsammans med observationer där utvecklarna fick prova på en första iteration avHCCR. Den första iterationen togs fram genom att använda företagets riktlinjer gällandehur utvecklare bidrar med kodändringar tillsammans med åsikter från handledaren påföretaget om hur verktyget kan fungera. Intervjuerna spelades in och transkriberades1När det kommer till ord och uttryck inom Git, (exempelvis commits, pull-request, push, pull) finnsdet ingen standardiserad översättning till svenska. Därför kommer dessa ord skrivas på engelska isammanfattningen.ivvarpå en tematisk analys genomfördes. Från analysen framträdde 13 koncept kringkodgranskning vilka delades in i fem kategorier. Utvecklarna önskade att varje commitskulle vara atomisk, kompilerbar samt testbar för att underlätta felsökning av buggar.Utvecklarna uttryckte också ett behov av att få tydlig information om både PR ochcommit-meddelanden. I intervjuerna framkom det att meddelandena borde bestå av:vad som har ändrats och varför det har ändrats. Det observerades även skillnader ikodgranskningsprocessen då olika utvecklare använder olika strategier när de granskarkod.Baserat på den information som framträdde från intervjuerna och observationernatillsammans med tidigare forskning utarbetades en andra iteration av HCCR. Rapportenavslutas med att diskutera möjliga implementationer av verktyget.

Det är sedan länge känt, både bland företag och i den akademiska världen, att det krävs strukturerade arbetsmetoder för att lyckas med storskalig programvaruutveckling. Vilka metoder som fungerar bäst är det svårt att göra ett generellt uttalande om eftersom detta till stor del är situationsberoende. Det existerar en ansenlig mängd metoder och processer som finns beskrivna i detalj av deras förespråkare, men ingen metod fungerar felfritt i alla situationer. I den här rapporten beskrivs de metoder en projektgrupp tillämpade under ett kandidatarbete i programvaruutveckling, och konsekvenserna dessa fick för den slutgiltiga produkten. Gruppen har kommit fram till att värde har skapats för kunden genom att implementera kundens begärda system, en interaktiv webbapplikation. Underhållbarhet har uppnåtts genom att följa en kodstandard, tillämpa parprogrammering och kodgranskningar samt publicera koden som öppen källkod. Att under möten diskutera gruppmedlemmarnas välmående bidrog till bättre sammanhållning och stämning och därmed ett bättre slutresultat. Många av gruppens svårigheter hade lösts om gruppen haft ett dedikerat kontor. Förhoppningen är att de erfarenheter och den kunskap som gruppen tillgodogjort sig under projektet, och dokumenterat i den här rapporten, ska komma till nytta för både projektmedlemmarna och rapportens läsare.

Carefully scanning and analysing web- applications is important, in order to avoid potential security vulnerabilities, or at least reduce them. Traditional code reviewing methods, such as manual code reviews, have various drawbacks when performed on large codebases. Therefore it is appropriate to explore automated code reviewing tools and study their performance and reliability. The literature study helped identify various prerequisites, which facilitated the application of automated code reviewing tools. In a case study, two static analysis tools, CodeQL and Semgrep, were used to find security risks in three open source web- applications with already known vulnerabilities. The result of the case study indicates that the automated code reviewing tools are much faster and more efficient than the manual reviewing, and they can detect security vulnerabilities to a certain acceptable degree. However there are vulnerabilities that do not follow a pattern and are difficult to be identified with these tools, and need human intelligence to be detected. / Det är viktigt att skanna och analysera webbapplikationer noggrant för att undvika potentiella säkerhetsproblem eller åtminstone minska dem. Traditionella kodgranskningsmetoder, såsom manuella kodgranskningar, har olika nackdelar när de utförs på stora kodbaser. Därför är det lämpligt att utforska automatiserade verktyg för kodgranskning och studera deras prestanda och tillförlitlighet. Litteraturstudien hjälpte till att identifiera olika förutsättningar, som underlättade tillämpningen av automatiserade kodgranskningsverktyg. I en fallstudie användes två statiska analysverktyg, CodeQL och Semgrep, för att hitta säkerhetsrisker i tre open sourcewebbapplikationer med redan kända sårbarheter. Resultatet av fallstudien indikerar att de automatiska kodgranskningsverktygen är mycket snabbare och effektivare än de manualla kodgranskningar och att de kan upptäcka säkerhetsproblem i viss acceptabel grad. Det finns emellertid sårbarheter som inte följer ett mönster och som är svåra att identifiera med dessa verktyg, och behöver mänsklig intelligens för att upptäckas.

Ensuring the health of a distributed system with frequent updates is complicated. Many tools exist to improve developers’ comprehension and productivity in this task, but room for improvement exists. Based on previous research within request flow comparison, we propose a system design for using distributed tracing data in the process of reviewing code changes. The design is evaluated from the perspective of system performance and developer productivity using a critical production system at a large software company. The results show that the design has minimal negative performance implications while providing a useful service to the developers. They also show a positive but statistically insignificant effect on productivity during the evaluation period. To a large extent, developers adopted the tool into their workflow to explore and improve system understanding. This use case deviates from the design target of providing a method to compare changes between software versions. We conclude that the design is successful, but more optimization of functionality and a higher rate of adoption would likely improve the effects the tool could have. / Att säkerställa stabilitet i ett distribuerat system med hög frekvens av uppdateringar är komplicerat. I dagsläget finns många verktyg som hjälper utvecklare i deras förståelse och produktivitet relaterat till den här typen av problem, dock finns fortfarande möjliga förbättringar. Baserat på tidigare forskning inom teknik för att jämföra protokollförfrågningsflöden mellan mjukvaruversioner så föreslår vi en systemdesign för ett nytt verktyg. Designen använder sig av data från distribuerad tracing för att förbättra arbetsflödet relaterat till kodgranskning. Designen utvärderas både prestanda och produktivitetsmässigt under utvecklingen av ett affärskritiskt produktionssystem på ett stort mjukvaruföretag. Resultaten visar att designen har mycket låg inverkan på prestandan av systemet där det införs, samtidigt som den tillhandahåller ett användbart verktyg till utvecklarna. Resultaten visar också på en positiv men statistiskt insignifikant effekt på utvecklarnas produktivitet. Utvecklarna använde primärt verktyget för att utforska och förbättra sin egen förståelse av systemet som helhet. Detta användningsområde avvek från det ursprungliga målet med designen, vilket var att tillhandahålla en tjänst för att jämföra mjukvaruversioner med varandra. Från resultaten drar vi slutsatsen att designen som helhet var lyckad, men mer optimering av funktionalitet och mer effektivt införande av verktyget i arbetsflödet hade troligtvis resulterat i större positiva effekter på organisationen.

Establishing and preserving a high level of software quality is a not a trivial task, although the benefits of succeeding with this task has been proven profitable and advantageous. An approach to mitigate the decreasing quality of a project is to track metrics and certain properties of the project, in order to view the progression of the project’s properties. This approach may be carried out by introducing continuous code inspection with the application of static code analysis. However, as the initial common opinion is that these type of tools produce a too high number of false positives, there is a need to investigate what the actual case is. This is the origin for the investigation and case study performed in this paper. The case study is performed at Ida Infront AB in Linköping, Sweden and involves interviews with developers to determine the performance of the continuous inspection platform SonarQube, in addition to examine the general opinion among developers at the company. The author executes the implementation and configuration of a continuous inspection environment to analyze a partition of the company’s product and determine what rules that are appropriate to apply in the company’s context. The results from the investigation indicate the high quality and accuracy of the tool, in addition to the advantageous functionality of continuously monitoring the code to observe trends and the progression of metrics such as cyclomatic complexity and duplicated code, with the goal of preventing the constant increase of complex and duplicated code. Combining this with features such as false positive suppression, instant analysis feedback in pull requests and the possibility to break the build given specified conditions, suggests that the implemented environment is a way to mitigate software quality difficulties. / 建立和保持高水平的软件质量可以带来经济利益等诸多好处，然而这是一项很困难的任务。其中一种防止软件项目质量下降的方法是通过跟踪项目的度量值和某些属性，来查看项目的属性的变化情况。通过引入持续的代码审查和应用静态代码分析方法可以实现这种方法。然而，在人们的印象中，这类工具往往具有较高的误检，因此需要进一步调查实际情况、研究其可行性，这是本文的初始研究目标。本文在瑞典林雪平的Ida Infront AB公司开展了案例研究，调研了该公司开发人员的意见，并通过访问开发人员，确定持续的代码审查平台SonarQube的性能。作者对持续的代码审查环境进行了配置，分析了公司的部分产品，进而确定哪些规则适用于该公司。调查结果表明该工具是高质量并且准确的，还提供了持续监测代码来观察度量值的趋势和进展等先进功能，例如通过监测环路复杂度和重复代码等度量值，来防止复杂度和重复代码的增加。通过组合误检压缩、对pull requests的瞬间分析反馈、以及分解和建立给定的条件等特征，使得所实现的环境成为一种可以降低软件质量保障难度的方式。