In the present work we study behaviour of tools intended for code review and how they aim at eliminating security vulnerabilities. There is a lot of such tools, but a smaller set of them suffice to effectively improve the security of software. We provide results of empirical testing of these tools on artificial data in order to map vulnerability classes they are able to identify and also on real data in order to test their scalability.

Peer code reviews play a critical role in maintaining code quality, and GitHub has introduced several new features to assist with the review process. One of these features is suggested changes, which allows for precise code modifications in pull requests to be suggested in review comments. Despite the availability of such helpful features, many pull requests remain unattended due to lower priority. To address this issue, we developed a bot called ``Suggestion Bot" to automatically review the codebase using GitHub's suggested changes functionality. An empirical study was also conducted to compare the effectiveness of this bot with manual reviews. The findings suggest that implementing this bot can expedite response times and improve the quality of pull request comments for pull-based software development projects. In addition to providing automated suggestions, this feature also offers valuable, concise, and targeted feedback. / Master of Science / Code review, often known as peer review, is a process used to ensure the quality of software. Code review is a process in software development that involves one or more individuals examining the source code of a program, either after it has been implemented or during a pause in the development process. The creator of the code cannot be one of the individuals. "Reviewers" refers to the individuals conducting the checking, excluding the author. However, the majority of reviewers won't have the time to examine and validate the peer's code base, so they'll assign it the lowest priority possible. This could cause pull requests to stall out without being reviewed. Therefore, as part of our research, we are creating a bot called SUGGESTION BOT that provides code changes in pull requests. The author can then accept, reject, or alter these ideas as a necessary component of the pull request. Additionally, we compared the effectiveness of our bot with the manual pull request review procedure, which clearly demonstrated that the incorporation of this bot significantly shortened the turnaround time. Besides giving automated recommendations, this functionality also provides useful, brief, and focused feedback.

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.

Nowadays more and more IT companies switch to the distributed development model. This trend has a number of advantages and disadvantages, which are studied by researchers through different aspects of the modern code development. One of such aspects is code review, which is used by many companies and produces a big amount of data. A number of studies describe different data mining and data analysis approaches, which are based on a link between code review data and performance. According to these studies analysis of the code review data can give a good insight to the development performance and help software companies to detect a number of performance issues and improve the quality of their code. The main goal of this Thesis was to collect reported knowledge about the code review data analysis and implement a solution, which will help to perform such analysis in a real industrial setting. During the performance of the research the author used multiple research techniques, such as Snowballing literature review, Case study and Semi-structured interviews. The results of the research contain a list of code review data metrics, extracted from the literature and a software tool for collecting and visualizing data. The performed literature review showed that among the literature sources, related to the code review, relatively small amount of sources are related to the topic of the Thesis, which exposes a field for a future research. Application of the found metrics showed that most of the found metrics are possible to use in the context of the studied environment. Presentation of the results and interviews with company's representatives showed that the graphic plots are useful for observing trends and correlations in development of company's development sites and help the company to improve its performance and decision making process.

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.

Software practitioners make technical and business decisions based on the understanding they have of their software systems. This understanding is grounded in their own experiences, but can be augmented by studying various kinds of development artifacts, including source code, bug reports, version control meta-data, test cases, usage logs, etc. Unfortunately, the information contained in these artifacts is typically not organized in the way that is immediately useful to developers’ everyday decision making needs. To handle the large volumes of data, many practitioners and researchers have turned to analytics — that is, the use of analysis, data, and systematic reasoning for making decisions. The thesis of this dissertation is that by employing software analytics to various development tasks and activities, we can provide software practitioners better insights into their processes, systems, products, and users, to help them make more informed data-driven decisions. While quantitative analytics can help project managers understand the big picture of their systems, plan for its future, and monitor trends, qualitative analytics can enable developers to perform their daily tasks and activities more quickly by helping them better manage high volumes of information. To support this thesis, we provide three different examples of employing software analytics. First, we show how analysis of real-world usage data can be used to assess user dynamic behaviour and adoption trends of a software system by revealing valuable information on how software systems are used in practice. Second, we have created a lifecycle model that synthesizes knowledge from software development artifacts, such as reported issues, source code, discussions, community contributions, etc. Lifecycle models capture the dynamic nature of how various development artifacts change over time in an annotated graphical form that can be easily understood and communicated. We demonstrate how lifecycle models can be generated and present industrial case studies where we apply these models to assess the code review process of three different projects. Third, we present a developer-centric approach to issue tracking that aims to reduce information overload and improve developers’ situational awareness. Our approach is motivated by a grounded theory study of developer interviews, which suggests that customized views of a project’s repositories that are tailored to developer-specific tasks can help developers better track their progress and understand the surrounding technical context of their working environments. We have created a model of the kinds of information elements that developers feel are essential in completing their daily tasks, and from this model we have developed a prototype tool organized around developer-specific customized dashboards. The results of these three studies show that software analytics can inform evidence-based decisions related to user adoption of a software project, code review processes, and improved developers’ awareness on their daily tasks and activities.

Introductory computer programming course is one of the fundamental courses in computer science. Students enrolled in computer science courses at the college or university have been reported to lack motivation, and engagement when learning introductory programming (CS1). Traditional classrooms with lecture-based delivery of content do not meet the needs of the students that are being exposed to programming courses for the first time. Students enrolled in first year programming courses are better served with a platform that can provide them with a self-paced learning environment, quicker feedback, easier access to information and different level of learning content/assessment that can keep them motivated and engaged. Introductory programming courses (hereafter referred to as CS1 and CS2 courses) also include students from non-STEM majors who struggle at learning basic programming concepts. Studies report that CS1 courses nationally have high dropout rates, ranging from anywhere between 30-40% on an average. Some of the reasons cited by researchers for high dropout rate are lack of resource support, motivation, lack of engagement, lack of motivation, lack of practice and feedback, and confidence. Although the interest to address these issues in computing is expanding, the dropout rate for CS1/CS2 courses remains high. The software engineering industry often believes that the academic community is missing the mark in the education of computer science students. Employers recognize that students entering the workforce directly from university training often do not have the complete set of software development skills that they will need to be productive, especially in large software development companies.

Background: Modern Code Review (MCR) is a process of reviewing code which is a commonly used practice in software development. It is the process of reviewing any new code changes that need to be merged with the existing codebase. As a developer, one receives many code review requests daily that need to be reviewed. When the developer receives the review requests, they are not prioritised. Manuallyprioritising them is a challenging and time-consuming process. Objectives: This thesis aims to address and solve the above issues by developing a machine intelligence-based code review prioritisation tool. The goal is to identify the factors that impact code review prioritisation process with the help of feedback provided by experienced developers and literature; these factors can be used to develop and implement a solution that helps in prioritising the code review requests automatically. The solution developed is later deployed and evaluated through user and reviewer feedback in a real large-scale project. The developed prioritisation tool is named as Pineapple. Methods: A case study has been conducted at Ericsson. The identification of factors that impact the code review prioritisation process was identified through literature review and semi-structured interviews. The feasibility, usability, and usefulness of Pineapple have been evaluated using a static validation method with the help of responses provided by the developers after using the tool. Results: The results indicate that Pineapple can help developers prioritise their code review requests and assist them while performing code reviews. It was found that the majority of people believed Pineapple has the ability to decrease the lead time of the code review process while providing reliable prioritisations. The prioritisations are performed in a production environment with an average time of two seconds. Conclusions: The implementation and validation of Pineapple suggest the possible usefulness of the tool to help developers prioritise their code review requests. The tool helps to decrease the code review lead-time, along with reducing the workload on a developer while reviewing code changes.

Background. Code reviewing is a commonly used practice in software development. It refers to the process of reviewing new code changes, commonly before they aremerged with the code base. However, in order to perform the review, developers need to be assigned to that task. The problems with a manual assignment includes a time-consuming selection process; limited pool of known candidates; risk of high reuse of the same reviewers (high workload). Objectives. This thesis aims to attempt to address the above issues with a recommendation system. The idea is to receive feedback from experienced developers in order to expand upon identified reviewer factors; which can be used to determinethe suitability of developers as reviewers for a given change. Also, to develop and implement a solution that uses some of the most promising reviewer factors. The solution can later be deployed and validated through user and reviewer feedback in a real large-scale project. The developed recommendation system is named Carrot. Methods. An improvement case study was conducted at Ericsson. The identification of reviewer factors is found through literature review and semi-structured interviews. Validation of Carrot’s usability was conducted through static analysis,user feedback, and static validation. Results. The results show that Carrot can help identify adequate non-obvious reviewers and be of great assistance to new developers. There are mixed opinions on Carrot’s ability to assist with workload balancing and decrease of review lead time. The recommendations can be performed in a production environment in less than a quarter of a second. Conclusions. The implemented and validated approach indicates possible usefulness in performing recommendations, but could benefit significantly from further improvements. Many of the problems seen with the recommendations seem to be a result of corner-cases that are not handled by the calculations. The problems would benefit considerably from further analysis and testing.

Background: With the development of software, its quality is increasingly valued by people. The developing technical ability was absolutely taken to underpin the performance of the developer, and code quality was raised as being related to developer performance, thus code quality could be a measure of developer performance. Developer performance is often influenced by multiple factors. Also, different factors have different impacts on developer performance in different project types. It is important for us to understand the positive and negative factors for developer performance in a certain project. If these factors are valued, developers will have better performance and project will have higher quality.   Objectives: The objective of our study is to identify how factors (developer experience, task size, and team size) impact the developer performance in each case. Though understanding how factors impact the developer performance, developers can have a better performance, which is a big benefit to the quality of project.   Methods: We decided to use the characteristics of commits during the Gerrit code review to measure the committed code quality in our research, and from committed code quality we can measure  the developer performance. We selected two different projects which use Gerrit code review as our cases to conduct our archive study. One is the legacy project, another is the open-source project. Then we selected five common characteristics (the rate of abandoned application code, the rate of abandoned test code, abandoned lines of application code, abandoned lines of test code and build success rate) to measure the code quality The box plot is drawn to visualize the relationship between the factor experience and each characteristic of the commits. And Spearman rank correlation is used to test the correlation between each factor and characteristic of commits from the statistical perspective. Finally, we used the multiple linear regression to test how a specific characteristic of commits impacted by the multiple factors.   Results: The results show that developers with high experience tend to abandon less proportion of their code and abandon less lines of code in the legacy project. Developers with high experience tend to abandon less proportion of their code in the open-source project. There is a similar pattern of the factor task size and the factor amount of code produced in these two cases. Bigger task or more amount of code produced will cause a great amount of code abandoned. Big team size will lead to a great amount of code abandoned in the legacy project.   Conclusions: After we know about how factors (experience, task size, and team size) influence the developers' performance, we have listed two contributions that our research provided:  1. Big task size and big team size will bring negative impact to the developer performance.  2. Experienced developers usually have better performance than onboarded developers. According to these two contributions, we will give some suggestions to these two kinds of projects about how to improve developer performance, and how to assign the task reasonable.