Background: In a sustaining, durable project, an effective code review process is key to ensuring the long-term quality of the code base. As the size of the software continues to increase, although the code inspections have many benefits, the time it takes, the manpower makes it not a good method in some larger projects.  Nowadays more and more industry performs modern code reviews for their project in order to increase the quality of the program. Only a few papers have studied the relationship between code reviewers and code review quality. We need to explore the relationships among code review, code complexity, and reviewers. Finding out which part of the code the reviewers pay more attention to in the code review and how much effort it takes to review. This way we can conduct code reviews more effectively. Objectives: The objective of our study is to investigate if code complexity relates to how software developers to review code in terms of code review length, review frequency, review text quality, reviewer’s sentiment. What’s more, we want to research if the reviewer’s experience will have an impact on code review quality. In order to find a suitable way to conduct a code review for different complexity codes.  Methods: We conduct an exploratory case study. The case and unit of analysis is the open-source project, Cassandra. We extract data from Cassandra Jira (a proprietary issue tracking product), the data are the reviewer’s name, review content, review time, reviewer’s comments, reviewer’s sentiment, comment length, and the review file(java file). Then we use CodeMR to calculate the complexity of the file, it uses some coupling and code complexity metrics. The reviewer’s sentiment is analyzed by a text analysis API. After we collect all these data we use SPSS to do a statistic analysis, to find whether there are relationships between code complexity and these factors. What’s more, we have a workshop and send out questionnaires to collect more input from Cassandra developers. Results: The results show that code review frequency is related to code complexity, complex code requires more review. Reviewer’s sentiment is related to code complexity, reviewer’s sentiment towards complex code is more positive or negative rather than neutral. Code review text quality is related to the reviewer’s experience, experienced reviewers leave a comment with higher quality than novice reviewers. On the other hand, the code review length and review text quality are not related to code complexity. Conclusions: According to the results, the code with higher code complexity related to the more frequent review, and the reviewer's emotions are more clear when reviewing more complex code. Training experienced reviewers are also very necessary because the results show that experienced reviewers review the code with higher quality. From the questionnaire, we know developers believe that more complex code needs more iterations of code review and experienced reviewers do have a positive effect on code review, which gives us a guide on how to do code review based on a different level of code complexity.

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.

[pt] O design de software é uma preocupação fundamental na revisão de código, por meio da qual os desenvolvedores discutem ativamente e melhoram cada mudança de software. No entanto, a revisão de código é uma tarefa colaborativa influenciada por aspectos técnicos e sociais. Consequentemente, esses aspectos podem desempenhar um papel fundamental em como o design de software se degrada. Eles podem contribuir para acelerar ou reverter a degradação do design durante o processo de revisão de cada mudança. No entanto, há pouco entendimento sobre: (i) o impacto da revisão do código e suas práticas na degradação do design ao longo do tempo; e (ii) em que medida os aspectos sociais e técnicos estão relacionados com a redução ou aumento da degradação do design. Abordamos essas limitações motivadas por dois objetivos. Nosso primeiro objetivo é fornecer uma caracterização de como as revisões de código modernas afetam a degradação do design durante a manutenção do software. Consideramos vários aspectos técnicos e sociais para estudar o impacto das revisões de código, utilizando técnicas de aprendizado de máquina. Nosso segundo objetivo é explorar o papel dos aspectos técnicos e sociais em distinguir e predizer mudanças de design (não) impactantes durante as revisões de código. Uma mudança de design é considerada impactante quando varia a densidade e a diversidade dos sintomas de degradação (ou seja, cheiros de código). Esses objetivos foram abordados em dois estudos empíricos. Nosso primeiro estudo relata uma caracterização do impacto das revisões de código na evolução dos sintomas de degradação ao longo de cada revisão de código. Também levamos em consideração quando havia um objetivo explícito ou discussões sobre design de software. Nosso segundo estudo relata uma análise dos aspectos técnicos e sociais que influenciam as mudanças ao longo de todas as revisões em uma única revisão de código. Então, pudemos observar o papel dos aspectos sociais em distinguir e predizer mudanças impactantes no design. Nossos resultados mostram que a maioria das revisões de código tem pouco ou nenhum impacto na degradação, mesmo com discussões explícitas de design. Longas discussões e uma alta taxa de discordância dos revisores aumentam o risco de degradação. Os aspectos sociais e técnicos são capazes de distinguir mudanças de design (não) impactantes. Em resumo, nossos resultados nos forneceram uma melhor compreensão dos aspectos influentes que nos ajudam a derivar diretrizes para mitigar a degradação durante as revisões de código. Nossos resultados também fornecem insights para projetar novas ferramentas de revisão de código, também capazes de alertar os desenvolvedores com antecedência sobre o impacto prejudicial do design ao longo das revisões de código. / [en] Software design is a key concern in code review through which developers actively discuss and improve each software change. Nevertheless, code review is a collaborative task influenced by technical and social aspects. Consequently, these aspects can play a key role in how software design degrades. They can contribute to accelerating or reversing design degradation during the process of each single change s review. However, there is little understanding about: (i) the impact of code review and their practices on design degradation over time; and (ii) to what extent social and technical aspects are related to the reduction or increase of design degradation.We addressed these limitations driven by two goals. Our first goal is to provide a characterization of how modern code reviews impact design degradation during software maintenance. We consider various technical and socials aspects to study the code reviews impact. Our second goal is to explore the role of technical and social aspects in distinguishing and predicting (un)impactful design changes during code reviews, using machine learning techniques. A design change is considered impactful when it varies the density and diversity of degradation symptoms (i.e., code smells). These goals were addressed with two empirical studies. Our first study reports a characterization of the impact of code reviews on the evolution of degradation symptoms along each code review. We also took into consideration when there was an explicit goal or discussions around software design. Our second study reports an analysis of technical and social aspects influencing changes along all the revisions within a single code review. Then, we could observe the role of social aspects in distinguishing and predicting design impactful changes. Our results show that the majority of code reviews have little or no impact on degradation, even with explicit design discussions. Long discussions and a high rate of reviewers disagreement increase the risk of degradation. Both social and technical aspects are able to distinguish design (un)impactful changes. In summary, our results provided us with a better understanding of influential aspects that help us in deriving guidelines to mitigate degradation during code reviews. Our results also provide insights to design a new code review tool salso able to warn developers early about the harmful design impact along code reviews.