We discuss the paper “Expectations, outcomes, and challenges of modern code review” [1] by A. Bacchelli and C. Bird
We started without a priori hypotheses…:
This is called a grounded theory approach
Why do programmers do code reviews?: Find defects, Code Improvement, Alternative Solutions, Knoweledge Transfer Team Awareness (self-reported)
Outcomes of code review: Improvements, finding defects, knoweldge transfer (through comment analysis)
Challenges when code reviewing: Understanding the code and the impact of the change, context is important, communication is important
What is Grounded Theory?
The main outcome of the paper is: “Code review is not (much) about quality improvement, but for sharing team knoweledge” How does this reflect your experiences?
How could we validate the findings of this paper
Read the paper: Modern Code Review: A Case Study at Google What analogies do we find between the two companies?
Why is this paper important?
by Zequn Zhou
Q: What is a socio-technical system? A: It is a process on which both the interaction between people and technological aspects have effect. They should both be taken in consideration when solving a problem. For example, nature is a technical system because people are independent of the nature itself. But a system involving both nature and people would be a social-technical system.
Q: How does code review improve team awareness? A: People need to communicate when solving a problem. Then they will have a deeper understanding about the goals and what each member of the team is working on.
Q: What kind of defects are found during code review? A: Code style, logic error and some corner cases
Q: How should one find out if the theory holds? A: Collecting data to confirm or finding a counter example
Then grounded theory was discussed. Grounded theory is often used when having no concrete idea of what to explore, for example in the form of a concrete theory.
Q: Why is this paper important? A: This paper introduces the concept of modern code review using grounded theory and useful data are obtained from quantitative exploration.
We discuss the paper The impact of code review coverage and code review participation on software quality: A case study of the Qt, VTK, and ITK projects, by McIntosh et al.[2]
by Zequn Zhou and Zina Wang
Q: What are the good aspects of this paper? A: It is a very detailed paper and the methods used in the paper are explained pretty well.
Q: How does the paper select the systems on which research is performed? A: According to the number of reviews.
Q: Why do they choose Gerrit? A: All code review messages are saved and easily retrievable, as opposed to previously used systems.
Q: How did team members discuss about their code before the invention of Gerrit? A: Through email. Then Gerrit was created. Then GitHub was created, which has a lot of users nowadays.
Q: What is a drawback of this paper? A: According to the extracted data, the delay before starting a code review cannot be discovered, which may affect the result.
Q: What is the optimal size for a code review group for highest efficiency? A: Someone thinks it should be 5 because in this case group members can be quite familiar with each other, which is helpful to the code review. But someone else feels like 5 members are too much because there will be too many code to review. 3 people would be better.
Q: Besides coverage and participation, what other code review related property can be considered to have an impact on software quality? A: Getting paid or not when doing the code review. It can improve the quality because people are motivated because of the money. But meanwhile it may decrease the quality because people just focus on the money.