You are here: SE » ThesesHome » ThesisCodeReviewatWork

Code Review at Work

This research is about code review at Capgemini. The goal of this research is to understand the different processes of code review process in order to improve it, the research will go through the following steps:

  1. Understand the different processes of code review by gathering information about them through interviewing the developers.
  2. Evaluate the collected data.
  3. Give suggestions to improve ­­­the code review processes.

This research focuses on the human and organisational aspects of code review rather than the technical aspects.

Requirements

  • Collect data about code review process at work
  • Overview about the GTM
  • Analyse the collected data
  • Give suggestion to improve code review process
  • Discuss and explain the suggestion

Interesting Aspects (Before Pilot Interviews)

  • Personal Estimate (I know from Code Review, how good I am)
  • Whether the code review is taken personally
  • Transfer of knowledge (learning and teaching)
  • Do they like to review code or it is only part of their job.
  • How to arouse the interest in code review
  • Who they like to review their code, why? (why is he good with code review)
  • When? Immediately after or a week later
  • When is a code review successful?

Current Interesting Aspects (After Pilot Interviews)

  • Relationship between the developers
  • Reputation of the developers
  • Knowledge Transfer and Learning
  • Experience
  • Time spent in the company, project or team
  • Valuation of oneself and others
  • Content of code review

The questionnaire focuses on technical and non-technical human aspects, such as on the experience of the reviewer and the author and on the relationship between them. In order to study how these aspects affects on the benefits of code review, such as knowledge transfer and learning for both author and reviewer.

Final Interesting Aspects ( After Interviewing and Coding)

  • Relationship between the developer and the reviewer
  • Knowledge
  • Feedback
  • Learning
  • Effects of Learning

Suggestions

Suggestions of this study are given to Capgemini to use them in their processes of code review. They are going to apply them in their current processes when possible and they are going to consider them when setting up the documentation of code review.

  • Estimate the current state of the relationship in order to know to manage the review.
  • All combinations of reviewer and author are useful; less experienced developers with more experienced developers and vice versa, new with old and vice versa…etc.
  • Exchange roles between reviewer and author.
  • Learning and spreading the knowledge should be from the beginning clear for the developers as a goal to achieve from the reviews. So the reviewer will acknowledge that part of their job is teaching.
  • Give priorities to the checklist's element and do not overstrain the author with 100 change-wishes at a time.
  • The feedback should be addressed to the code and not to the developer. (To the developer only when needed)
  • Enlighten the importance of positive feedback
  • Phrasing the review comments humbly and encouragingly
  • Phrasing the comments in the form of a question
  • Encourage peer review and meeting-based review from time to time rather than doing only tool-based reviews. So the developer would get to know each other and communicate.
  • Reviewers and authors must work together outside the reviews, so each needs to maintain a level of professionalism and mutual respect to avoid strained relationships.

Protocol

TimeSorted descending Occupied with
August Questionnaire preparation, Pilot Interviews, Improve questionnaire iteratively.
25-31 Oct Prove every arrow in the diagram and find extreme examples
15-25 Sep Typing the interviews and open-coding them
10-24 Oct Create coding paradigm
10-20 Nov Suggestions
7-9 Nov Find a story telling/ story example and think of suggestions
4-15 Sep Collection of data: Interviewing the developers
4-9 Oct Axial coding: Read about it and then apply it.
1-6 Nov Write the grounded theory section
20 Nov - 8 Dec Aufschreiben
25 Sep - 3 Oct Review the transcripts to ensure that all the important information is coded. Then, ensure that all coded information is categorised or coded as it should be.

Comments