To Code Review or not to Code Review. How to do it better and what results can you excect? Answers inside.

1. Code Review

2. Code review – assumptions
• Regularity
• Each, even the slightest change is checked and needs to be
accepted
• We review the code quality and readability (coding standards)
• We look for any potential errors and optimization
opportunities
• We give tips and advice!
• Code review = testing

3. to Code Review or not to Code Review
• Improved readability and quality of the created code
• Detection of errors and potential logical loopholes
• First step to identify any potential problems with application
performance
• Increase in the knowledge and skills of the team members

4. to Code Review or not to Code Review
• Time-consuming (app. 1h needed to review 300 lines of the code)
• Much knowledge and accuracy required
• Task performance speed is reduced
• Quality and accuracy of the code review depends on the person
performing it
• Your co-workers may begin to hate you :)

5. Five hints
1. Smaller changes are easier and quicker to analyze
2. Code review should take less than 1h a day
3. Code review is asynchronous, do it when you have the time
4. Positive approach! Evaluate the code, not the programmer
5. Code review should involve the whole team

6. Process that we apply
1. The code is reviewed by the programmer first
2. Next, we create a merge request and change the task status to
`To Code Review`
3. We review the code, adding comments and advice
4. The programmer adjusts the code and changes the task status to
`To Code Review` (unless no improvement is needed)
5. We repeat steps 3 and 4 until a satisfactory form of the code is
achieved
6. After the code is accepted, we merge the branch and the task is
passed on to further stages

7. We use GitLab to review the code

8. We use GitLab to review the code

9. We use GitLab to review the code

10. What do we consider
• Coding standards
• Descriptions of functions and classes
• Proper exception handling
• Logging the application status at crucial spots
• Compliance with the MVC pattern and Magento structure
• Potential logic errors
• SQL queries
• Performance

11. After three months:
• 150 merge requests
• About 10 performance problems detected in the result of the
code review
• 90% of poor code style less
• 99.9% of our methods and classes have a docblock
• Our code is better and more readable
• Every day, we learn from each other

12. Piotr Studnicki
sales@divante.co
divante.co/blog
Thank you!