RFC: Evaluating Value vs Pain for Code Reviews

amexboy

Amanu

Posted on November 8, 2023

RFC: Evaluating Value vs Pain for Code Reviews

Hi Esteemed members of Dev.to

I am working on creating a questionnaire to evaluate the performance of Code Reviews. As you may have already seen on this year’s State of DevOps Report, code reviews have a huge impact on organization performance. It certainly makes a great argument for pair programming.

In order to surface the miss-givings of code review culture and process of a team, data collection is a necessary step. Hence, I’ve taken the first step to designing a questionnaire that would help provide data to answer the value vs pain/loss of pull requests. I would like to get some comments on my questionnaire design.

Here are the questions I am trying to answer:

  1. How much time is lost in waiting for code reviews?
  2. How much of a developer’s time is spent reviewing code?
  3. Are they accomplishing their target or preventing bugs and design degradation?

Please leave me your comments on what you think about the questions. I would like to know

  1. If the questions were clear and unambiguous
  2. If the options were sufficient and fair
  3. If you think I should add more questions
  4. Or maybe you think there is a better way of accomplishing my goal

The Questions

Here are the list of questions I’ve developed so far.

  • Are you a default/required reviewer?
    • yes/no
  • During the past month, how much time did you typically dedicate to reviewing code in a given day?
  • During the past month, how many code reviews did you perform per day?
  • During the past month, how many change requests took you longer than 15 minutes to review in a given day?
  • During the past month, how long in average did you have to wait for your code to be reviewed?
  • When you review code, how much do you agree with the following statements? More often than not, I
    • can identify the changes made
    • have a clear understanding of the changes made
    • have a clear understanding of the context (reason) for the changes made
    • have sufficient time to conduct a comprehensive and high-quality review
    • feel confident to approve after a review
  • What is the average size of changes you review?
  • Do you feel responsible when code you approved introduces issues in the production environment?
  • How valuable do you perceive code reviews to be (Very Valuable, Somewhat Valuable, No Value)
    • maintaining code quality
    • knowledge sharing
    • preventing functional/logical issues
    • preventing performance issues
    • preventing security issues
    • maintaining system design/architecture
    • fostering team collaboration
  • What do you primarily focus on when reviewing code change? (Select 3)
    • maintaining code quality
    • knowledge sharing
    • preventing functional/logical issues
    • preventing performance issues
    • preventing security issues
    • maintaining system design/architecture
    • fostering team collaboration
  • How often do you give or receive comments regarding: (Very frequently, Here and There, Rarely)
    • maintaining code quality and formatting
    • functional/logical issues
    • performance issues
    • security issues
    • system design/architecture
  • When you create a change request, do you trust reviews to identify bugs (functional, logical, performance, or security issues)?
  • Of the functional, logical, performance, or security issues discovered during QA, how many of them could have been identified during a code review?
  • What are the frequent reasons for buggy code getting past code review?

I hope to hear from you; Adios

💖 💪 🙅 🚩
amexboy
Amanu

Posted on November 8, 2023

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related