Author: leomachadop | Affiliation: Mackenzie | Email: leomachadop@gmail.com | Date: 06/2016

Code review is the practice of a team member checking and reviewing code written by another member. Given this scenario, we can ask the following questions:

• Do professionals enjoy performing reviews?
• Do they believe this can make a difference in their work environment?
• Do different segments in information technology influence how the review is conducted?
• Does experience change how professionals conduct reviews?

Considering these questions, the aim of the work is to assess whether the practice of code review can aid in software development within companies, through a questionnaire developed and applied using statements found in the literature.

1. Introduction

Software development teams are constantly guided by various challenges in their daily routines. Complex tasks alone consume a lot of effort and, even so, after completion, they may result in failures or issues not found during development, even with unit tests. Regardless of the project, software quality must be valued at all times, from requirements gathering to system deployment.

According to CZERWONKA et al. (2015), there are several reasons why code review is used in the context of software engineering, among which stand out:

• Finding defects;
• Ensuring long-term maintenance of the code;
• Knowledge dissemination tool;
• Communicating continuous progress.

ANICHE (2013) states that code review has proven to be very effective in transferring knowledge to team members. When the reviewer examines the produced code, the person being reviewed explains the reasons for doing it that way and why certain tools were used, which greatly contributes to the professional and the team as a whole.

FAGAN (1976) proposed the idea of formal code review, also known as code inspection, which spread rapidly. In the proposed model, people have specific roles and should have the following functions:

• Moderator: Considered the key person, not necessarily a technical expert or specialist in the software being inspected, helping to maintain the objectivity of the inspection. Should lead the team performing the inspection;
• Designer: Responsible for designing the program;
• Programmer: Responsible for translating the design into code;
• Tester: Programmer responsible for performing test cases or other forms of testing the designer/coder's product.

In the model proposed by FAGAN (1976), at the end of the review, the moderator should produce a report with everything discussed and said during the inspection to ensure that all issues raised during the inspection are addressed in the rework.

FAGAN (1976) states that the ideal team for code review consists of 4 people, although this can vary depending on circumstances. If the code belongs to more than one programmer, the involved parties may conduct the code inspection. Inspections should be scheduled and managed with the same attention as other parts of the project, otherwise, they may be postponed or even avoided. The result in the short term has a negative effect, and repeated postponement may extend the overall schedule and increase project costs.

CZERWONKA (2015) states that inspections were conceived as formal meetings where participants prepare in advance. Unlike formal inspections, code review does not require participants to be in the same place or at a fixed time, facilitating reviews in geographically distributed teams.

According to BACCHELLI (2013), modern code review is a more informal process than proposed by FAGAN (1976) and can be done with the support of tools, personal meetings, and checking with the collaborator. COHEN et al. (2006) presents five ways to conduct code reviews:

• Formal inspections: Model proposed by FAGAN (1976);
• Over-the-shoulder: The author requesting the review shows the changes made to a team member, who examines and discusses what has been done. If the reviewer finds something wrong, pair programming can be done to find the best solution;
• E-mail pass-around reviews: The author sends the code to people they want to review it. These examine the files, ask questions, and discuss with the author and others the necessary changes. This technique may generate high email exchange and difficulties in data collection;
• Tool-Assisted reviews: Modern mechanism for performing code reviews with specialized tools that collect, transmit, and display files, comments, and defects, as well as collect metrics for greater visibility on the obtained numbers;
• Pair Programming: In the agile methodology eXtreme Programming (XP), the code is produced by two people, who alternate activities as determined by the company or the pair. This verification process is important to avoid errors in development and is a form of code review.

COHEN et al. (2006) states that some groups of programmers do not use code review due to two reasons:

• Ego;
• The work of performing code review.

Regarding ego, COHEN et al. (2006) states that when someone is evaluating the code, the person being evaluated may see the process as constructive or a criticism. This can lead to two classes of programmers: collaborators who, when confronted with problems, will try to solve them and see code review as something beneficial to the project; and isolationists, who will continue to try to solve problems alone without seeking help. COHEN et al. (2006) also emphasizes that this is not exclusive to programmers and can occur on a larger scale among professionals.

1.1 Objectives

1.1.1 General Objective

The objective is to verify how IT professionals accept the code review process and evaluate how this process occurs.

1.1.2 Specific Objectives

The specific objectives of the project are as follows:

• Verify if professionals conduct reviews, and if so, how they do it;
• Verify if professionals believe this practice increases software quality;
• Verify if professionals enjoy conducting reviews or if they oppose this practice;
• Improve how reviews are conducted and how they can be better applied according to the company;
• Verify how they feel when reviewing code and when being reviewed;
• Evaluate how code review can assist in a software development project.

1.2 Research Problems

According to TERVONEN (1997), the difficulty in controlling the quality of the inspection lies in the fact that it is a mental task and cannot be directly observed. This means it is challenging to use control metrics to know if the inspector is truly focused and assess when the inspection process is complete.

Conducting research within corporate environments is extremely difficult, as companies treat their source code and information with confidentiality. Employees are often required to sign information security agreements that prevent them from discussing the project. For this work, it would be interesting to analyze developer commits and comments, in addition to applying the code validations done in ANICHE (2013) research. Therefore, the research will be conducted in the form of a questionnaire with complete confidentiality of personal data.

1.3 Justification

The research should be conducted so that IT companies, regardless of the software development process, analyze and verify the levels at which professionals can be better at reviewing code and being reviewed. Results on how professionals prefer the review to be conducted can also be obtained.

With the results obtained, companies can determine if the practice of code review is appropriate in their software development process and how it should occur. Among the benefits, we can mention and measure when the professional may feel uncomfortable with this practice, which can cause problems within the team. The research aims to assist companies regarding the team's well-being.

The major contribution the research can offer is to verify if professionals truly believe that software quality increases with this practice or if it may not help during development, depending on the level of qualification. We can assume that quality, as presented by ANICHE (2013) and BACCHELLI (2013), is indeed elevated, but this research aims to show if professionals believe this practice can be incorporated into their daily routine without causing problems within the team.

The work will provide solutions on how to conduct code review, what forms it can take, and what contributions can be obtained when adopted, analyzing the results of the field research to be conducted.

2. Literature Review

As mentioned by COHEN et al. (2006), code review can affect the personal side of programmers, as many do not feel comfortable when their code is reviewed. The author proposes that in scenarios with constant changes in requirements, agile methods are preferable to traditional ones, such as the Waterfall model. Additionally, COHEN et al. (2006) highlights that code review is an important way to maintain code quality and should be done before the code enters the client's environment, to minimize impacts. Direct benefits cited include:

• Improvement of code quality;
• Reduction of code defects;
• Improvement in communication about code content;
• Education of junior programmers.

Indirect benefits include:

• Shorter development/test cycles;
• Reduced impact on technical support;
• Increased customer satisfaction;
• More sustainable code.

COHEN et al. (2006) also presents the social effects of code review, pointing out two ways that can negatively affect the social environment of the development team:

• Hurting feelings: Criticisms may be poorly received and provoke negative reactions, especially if the issue is complex;
• "Big Brother" effect: When software monitors the developer's activities and automatically measures comments.

CZERWONKA (2015) states that code review:

• Often does not find functionality issues that should block a code submission;
• Should be performed by people with a specific set of skills;
• The social aspect of code reviews cannot be ignored.

CZERWONKA (2015), based on data obtained from Microsoft, found that 15% of comments provided by reviewers indicate a possible defect, and less than 15% represent blocking defects. 50% of comments are general feedback on the code, and 33% are considered useful by the reviewed. The study also revealed that developers spend an average of six hours per week reviewing colleagues' code, which can be costly and complex. The author concludes that code review may not be performed efficiently, which is increasing costs. The research highlights that for Microsoft, code review is more effective in team training than in detecting software issues.

In the work conducted by ANICHE (2013), a comparison was made between two projects at Caelum to assess whether code review practice really helps in detecting issues. The research showed that, although defect numbers did not change significantly after review, knowledge dissemination and perceived quality improvement were notable. This study highlighted the importance of the human aspect in quality perception, even when metrics do not show a significant increase.

BACCHELLI (2013) discusses that in the 1970s and 1980s, code reviews were more formal and time-consuming. Currently, the process is lighter and less formal, with a greater focus on defect detection. Modern code review, with tools like CodeFlow, allows annotations directly on the code and interaction with the developer. The research indicated that developers expect to find defects, maintain team consistency, improve code quality, and evaluate design. The review is also seen as an opportunity for learning and knowledge transfer.

MANTYLA (2009) found that 75% of defects detected during code review do not visibly affect software functionality but are important for software evolution. Defects that prevent code evolution were also identified, being more valuable in long-lifecycle software.

BOEHM (2001) estimates that 60% of defects can be captured during code review and that identifying defects in the early stages of development is more cost-effective than finding them later. Factors influencing defect capture include review types, system size and complexity, and algorithm concurrency.

SIY (2001) proposes that 75% of defects found during code reviews are evolution problems affecting future development, rather than production errors.

According to TERVONEN (1997), inspections are used as software quality assurance techniques early in the software development process, i.e., well before coding. The development process follows this sequence:

Figure 1 Core of Software Production

TERVONEN (1997) describes the main inspection phases at the start of software development:

• Initial Meeting: Inform expectations and distribute documents, assign roles, and train in inspection procedures;
• Individual Inspection: Raise as many issues as possible and record improvements;
• Editing: Evaluate and classify issues as defects or non-defects;
• Follow-up: The inspection leader reviews and requests necessary changes.

KEMERER (2009) investigated the impact of design and code review on software quality and found that defects identified in the early stages are cheaper to fix. Inspection is considered the most effective technique, with rules such as:

• Ideal number of inspectors: four;
• Preparation rate: 100 lines per text/hour;
• Evaluation rate: about 125 lines of code per hour;
• Inspection meetings should not last more than two hours.

GILB (1994) suggests a preparation rate of 0.5 to 1.5 pages per hour and, for critical documents, 0.1 page per hour.

3. Summary of Research and Results

The goal of this research was to assess IT professionals' perceptions of code review and its impact on the work environment. For this, a questionnaire with 15 questions was developed and answered by 16 professionals from various IT sectors. The survey used Google Forms to facilitate data collection and analysis.

The results were presented in graphs and included information about participants' experience levels, types of code review they have used, and their perceptions of the benefits and challenges of this practice. Data revealed, for example, that most participants consider code review valuable for software quality and learning, and that review often helps avoid defects in production.

For complete details and the questionnaire, access the original work available on LinkedIn. For more information or clarifications, please get in touch.

4. Conclusion and Future Work

The results obtained from the questionnaire corroborate the research presented in the literature review, demonstrating the relevance of code review across various activity sectors of the interviewees. The analysis suggests that code review is an essential aspect that should be continuously evaluated and applied within companies.

The research involved 16 professionals, 12 (75%) of whom are experienced, with over five years of experience in IT, and 4 (25%) have less than five years of experience. This composition enriches the research, providing a balanced view by evaluating both experienced professionals and those with less time in the field.

Among code review practices, pair programming was the most cited, with 75% of respondents reporting that they have used it in their careers. This practice is widely known and adopted in IT companies. Next, the "over-the-shoulder" review practice was mentioned by 62.5% of participants, possibly due to its simplicity, as the reviewer is approached at the commit moment to review the code, without the need for a real-time process like in pair programming.

Regarding the values associated with code review, 93.8% of respondents highlighted the importance of increased quality, corroborating what the literature indicates. Increased learning was also mentioned, as the reviewer understands the technology to suggest improvements and, if not understood, learns from the reviewed.

As for daily challenges, 62.5% of respondents prefer to try to solve problems on their own before seeking help, while 37.5% seek help to resolve issues more quickly. Considering that 75% of respondents have over five years of experience, it can be concluded that most of these more experienced professionals tend to solve problems on their own.

When starting a new software project, 87.5% of respondents prefer code review over reading specification documents, indicating that code is seen as a more direct and practical way to understand the system and its business rules. Only 12.5% prefer formal documentation.

In the role of reviewer, 68.8% of respondents feel comfortable pointing out problems in the code, although 31.3% feel more at ease with close acquaintances or have difficulties communicating issues. This suggests that code review may be more effective when conducted in a comfortable and familiar environment. Alternatively, using emails for review might be a solution for cases where personal contact is not ideal.

As reviewed individuals, 68.8% are willing to learn from identified problems, and 31.3% depend on how the reviewer presents the issues. None of the respondents showed resistance to feedback or suggestions during the review, which is a positive sign for the acceptance of the review process.

When asked about recommending code review in a company that does not have it, 93.8% of respondents answered affirmatively, while 6.3% would not recommend it due to negative past experiences. This data indicates a strong acceptance of code review as a beneficial practice.

Regarding learning new techniques or technologies, 50% of respondents stated that learning occurs mainly when new technologies are used in projects, while familiarity with existing technologies leads only to improvements.

Regarding defect prevention in production, 93.8% of respondents believe that code review contributed to avoiding defects, while 6.3% said they take extra care during the commit. These numbers highlight the effectiveness of code review in preventing production issues.

Regarding motivation to conduct code reviews, 75% of respondents approach the process neutrally, merely fulfilling a requirement, while 25% show enthusiasm. This suggests that, although most recognize the importance of code review, it may be seen as a bureaucratic process by some.

Regarding automated code review tools, 75% of respondents do not use them, 18.8% use them, and 6.3% are unaware of these tools. The lack of tool usage may indicate an opportunity to optimize the code review process, reducing the time needed for preliminary analysis.

The analysis of the professionals' segments and their code review experiences reveals a variety of practices and opinions, helping to understand how review fits into different IT contexts. Participant comments highlight the usefulness of techniques like email for review, the importance of not drastically changing functionalities during review, and the relevance of review for learning and continuous improvement.

Future Work:

Future steps for this research include conducting practical tests beyond questionnaires, such as tracking code review progress empirically. It is important to maintain diversity among professionals involved and evaluate not only one project but several projects from different companies. This will allow a broader understanding of the practical effects of code review in different contexts and with a greater variety of technologies and development methodologies.

References

ANICHE, Maurício F.; SOKOL, Francisco Z. Efeitos da Prática de Revisão de Código na Caelum: Um Estudo Preliminar em Duas Equipes. 2014. Disponível em: http://www.aniche.com.br/wp-content/uploads/2013/04/wbma-final3.pdf. Acesso em: 23 jun. 2016.

BACCHELLI, Alberto; BIRD, Christian. Expectations, Outcomes, and Challenges of Modern Code Review. 2013. Acesso em: 20 jun. 2016. DOI: 978-1-4673-3076-3/13.

BOEHM, Barry; BASILI, Victor R. Top 10 List [Software Development]. 2001. Acesso em: jun. 2016. DOI: 10.1109/2.962984.

COHEN, Jason; BROWN, Eric; DURETTE, Brandon; TELEKI, Steven. Best Kept Secrets of Peer Code Review. Austin, TX: Smart Bear, 2006. Disponível em: http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf. Acesso em: 20 jun. 2016.

CZERWONKA, Jacek; GREILER, Michaela; TILFORD, Jack. Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down. 2015. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSE.2015.131.

FAGAN, M. E. Design and Code Inspections to Reduce Errors in Program Development. Journal IBM Systems Journal, Riverton, NJ, USA, v. 38, n. 2-3, 1976. DOI: 10.1147/sj.382.0258.

FAN, C-F.; YIH, S. Prescriptive Metrics for Software Quality Assurance. 1994. Acesso em: jun. 2016. DOI: 10.1109/APSEC.1994.465237.

GILB, Tom; GRAHAM, Dorothy. Software Inspection. 1. ed. Wokingham, England: Addison-Wesley Professional, 1994.

KEMERER, Chris F.; PAULK, Mark C. The Impact of Design and Code Reviews on Software Quality: An Empirical Study Based on PSP Data. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

MANTYLA, Mika V.; LASSENIUS, Casper. What Types of Defects Are Really Discovered in Code Reviews?. 2009. Acesso em: jun. 2016. DOI: 0098-5589/09/$25.00.

TELES, Vinícius Manhães. Programação em Par. 2006. Disponível em: http://www.desenvolvimentoagil.com.br/xp/praticas/programacao_par. Acesso em: 23 maio 2016.

TERVONEN, Ilkka; IISAKKA, Juha. Monitoring Software Inspections with Prescriptive Metrics. 1997. Department of Information Processing Science, University of Oulu, Oulu, Finland.

SIY, Harvey; VOTTA, Lawrence. Does The Modern Code Inspection Have Value?. 2001. Acesso em: 20 jun. 2016. DOI: 10.1109/ICSM.2001.972741.