Skip survey header

Code review changes - report - Tracecompass

Welcome, this is the report we created for your project.

We analysed the reviews that have been merged in the last year, focusing on which changes were applied to the code under review.

We found out that you successfully merged 477 reviews!

(please, note that we restricted the scope of our tool only to the Java files in your project)
Code changes happening during code review in your project
 
How does your code change thanks to the work your team puts during the reviews? The code changes that happen during the review process are, substantially, one of the main outcomes of the code review process. We call them review changes. How do these review changes look like in your project?

We could classify the review changes that happened during your code review process in two main categories:

1. Functional changes
2. Evolvability changes


1. Functional changes impact how the program functions. A reviewer may require a functional change to the code, for instance, to check how the variables or resources are used, as well as to improve an algorithm. 

Here an example from your project:

 
Link to review



2. Evolvability changes do not directly impact the functionality of a program, but make the software more maintainable and easier to evolve.

Examples of evolvability changes are reorganising the code, removing dead lines, and adding a comment.
Most of the changes that happen during the reviews in your projects are evolvability changes. For this reason, we further divided the Evolvability changes in 3 groups:


2.1 Documentation: Changes that tackle any issue in the documentation of the code. They include changes to comments and names in the program. 

An example from your project:

 
Link to review

2.2 Visual Representation: Changes that modify the layout of the code. In other words, any formatting that does not impact the compilation result.

An example from your project:

 
Link to review

2.3 Structure: Changes to the organisation of the code itself or how a particular solution is implemented (without having an effect on the functionality of the code). 

 
Link to review
Visualising Review Changes Stats

This is a mock-up of our tool interface. Please take into account the space limitation; the following figure is meant to just give a general overview of the data. Our tool interface adds three new visualization on the bottom of the page.

The single graphs will be shown again with more details later in the report. 

The graph in the bottom left shows the number of reviews merged per month.

The graph in the middle shows the amount of review changes according to the types we have presented before: Documentation (2.1), Visual representation (2.2), Structure (2.3) and Functional (1).

The graph in the bottom right shows the distribution of the review changes over the last year. 
1. After you have looked at this interface for your project, it would be great if you could let us know what you think about it:
Space Cell Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
The information is clear and easy to understand
This summary is useful for my project and contains relevant information
This information can be useful for a developer
This information can be useful for a project manager
This information reflects my expectations of the code review process of the project
Details - Chart 1

This graph shows the amount of changes per group happened in your code review process from August 2019 to September 2018. 


 
3. After you have looked at this visualization, it would be great if you could let us know what you think about it:
Space Cell Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
The graph is clear and easy to understand
This summary is useful for my project and contains relevant information
This information cab be useful for a developer
This information can be useful for a project manager
This information reflects my expectations of the code review process of the project
Details - Chart 2
 
This visualisation shows the amount of code review changes per group during last year.
Please take note that this chart uses two scales: one for functional changes (right), one for evolvability changes (left).



 
5. After you have looked at this visualization for your project, it would be great if you could let us know what you think about it:
Space Cell Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
The graph is clear and easy to understand
This summary is useful for my project and contains relevant information
This information can be useful for a developer
This information can be useful for a project manager
This information reflects my idea of the temporary distribution of the changes in our review
Considering all the information seen so far, it would be great if you could give us some feedback by answering the next few questions:
7. The whole report is useful for my project and contains relevant information.
Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
8. I have learned something about my project that I have not been aware of before.
Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
9. The results made me curious. I plan to investigate further the code review process of my project. 
Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
10. This report provides information that is not available in any other tool I know. 
Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
11. Having this kind of information at ready would have a positive influence over the Code Review process of my team. 
Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
12. Based on the information you have seen in this report, I would change something in the code review practices of my project:
Space Cell Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
Code review policies (e.g., mandatory review after each commit)
Use of tools (e.g., static analysis tools like Check style or FINDBUGS)
Reviewers assignment (e.g., by finding specific reviewers for specific defects)
13. I think that the information of this report might help with ...
Space Cell Strongly DisagreeDisagreeNeutralAgreeStrongly AgreeNo Answer
To understand how resources are spent on our project
To avoid performing the same mistakes again
Background
 
To improve the scientific validity of your feedback, It would be great if you could answer to the following demographic questions too. 
15. What is your involvement with the development of the project analyzed in this report?
16. What is your current job?
17. How many years have you developed software in a professional setting? 
I have no experience in software development in a professional setting1 year or less2 years3-5 years6-10 years11 years or more
18. How often do you currently program software?
Not at allAbout once a yearAbout once a monthAbout once a weekDaily or more often
19. How many years have you performed code reviews?
I have never done code review1 year or less2 years3-5 years6-10 years11 years or more
20. How often do you currently perform code reviews?
Not at allAbout once a yearAbout once a monthAbout once a weekDaily or more often
(Selecting "yes" allows other researchers and the public to benefit from your answers and effort)
Thank you very much for reading our report. We hope it gave you useful insights! Also, we thank you for the time you spent giving us feedback.

You are awesome!

If you are interested in the detailed data that we used to create this report, don't hesitate to contact us at: fregnan@ifi.uzh.ch