Quality

Reviewing a merge request

Reviewing a merge request is an important responsibility. It is the last step before code is merged into the main branch. It is also a great opportunity to learn from your colleagues and to share your knowledge with them.

How to communicate feedback

When reviewing a merge request, you should always provide feedback. This feedback should be constructive and actionable. It should also be clear and concise. While reviewing make sure that your comment is considerate and professional.

Since tone is difficult to convey in text form, it’s important to be mindful of how your feedback might be interpreted. The best way to do this is to use the Conventional Comments standard.

This means comments are prefixed with meaningful labels such as: Nitpick, Praise and Issue. This helps the author understand the context of the feedback and how to respond to it. Not all comments are blocking and often don’t need follow up work.

Code Review Checklist

Code reviews are completed by following this checklist. Check if the commit meets these standards:

1. Accessibility - pay attention to:

• Semantic HTML

• Presence of necessary alternative text, ARIA Attributes, titles for links

• Page structure to make sense on screen readers

• ♿️ Follow Accessibility Checklist to provide accessible features:

  Accessibility checklist

2. Optimisation:

• Styles and scripts minification
• Check if any of the scripts can be replaced with CSS
• Fonts loading
• Using SVGs instead other images formats
• Take care not to load all resources from the server once - if it’s possible to use lazy loading
• If possible download external resources instead of linking them

3. Naming conventions

• Proper file names
• Meaningful variable names
• Function names strictly connected with their task

4. Avoiding duplication

• Try using generic mixins, classes, functions, and components that can be reused
• Check existing SCSS variables and use them for colours, fonts, sizes, and so on.

5. Housekeeping details

• Removing unnecessary comments
• Removing console log statements and debugging code

6. Self-explanatory code and/or well-commented:

• If possible specify the purpose of the function or class and write comments for more complex algorithms
• Large code block should be described with JS DOC formula

7. Files structure

• Check if new files are allocated in the correct place in the folder tree
• Keeping files in designated folders and creating new ones if needed