Code reviews
Last updated: 10 April 2025
Code reviews are a vital part of the software lifecycle. They can keep code quality to a high standard as well as share knowledge between team members.
Solution
Code reviews should be part of your team’s workflow
Time should be allocated as part of your sprint to review code, as it’s important to keep high coding standards.
Code reviews should be constructive and friendly
When reviewing code, you should focus on the code, not the author. Remember that every developer has different ideas and solutions to problems. Using reasons to explain why something needs changing is much more valuable than expressing your feelings.
Point out the good things as well as bad
Positive feedback can help build a positive culture within your team, and it’s always nice to hear positive feedback.
Have a pull request template
A pull request template can help you create a checklist of what to do before/while creating a pull request, it can also be useful for the person reviewing the code. You can find an example in our engineering guidance and standards repository.
Support your code reviews with automation
Automate as much as possible to help relieve the code review burden, things like testing and linters can be automated. Tools like ESLint and Prettier can help with this.
Considerations
Some of the things that should be checked for
This is not an exhaustive list, just some recommendations. Your team should have their own standards. A pull request template can help with this by creating a checklist of what to look for.
- Does it work as intended?
- Ensuring that code works as intended is a crucial part of the code review process because it verifies functionality, prevents bugs and errors from reaching production, which saves time and resources. It also ensures a smooth and reliable user experience, maintaining user trust and satisfaction.
- Is it tested?
- Testing code is important, make sure to check that current tests are passed and make suggestions where further automations would help.
- Is it easy to read?
- Readability is important because it makes the code easier to understand, refactor, maintain and debug, ensuring that developers can work on it effectively in the future.
- Is the software well designed?
- Checking for things such as good error handling and logging can help developers debugging and provide a better user experience. Making sure the code fits with the rest of the project is also important. Finally checking if they have missed any edge cases or you can see any performance issues or bugs.
- Does the code protect against misuse?
- Protecting against security vulnerabilities is crucial, checking for things such as allowing code injection, not validating user inputs or including Personally Identifiable Information (PII) in error messages will help to catch problems early.
- Do the changes consider existing code?
- Reusability is important because it enhances efficiency and minimises errors and leads to faster development and makes code easier to maintain. Frameworks, tools and standards within a team can also help a developer reuse functions they provide, make sure to check that code can’t make use of these sources. Pay particular attention to this if the code may have been generated by AI which is not aware of shared functions/services etc.
- Is the code documented
- Documentation ensures that teams can more easily maintain and develop a codebase further. Checking that you’re happy with the level of documentation, especially if you were to work on this code in the future.
- Does it follow standards?
- Standards are important to help maintain high quality code, make sure to check that code follows the teams standards, SEGAS standards and the service manual standards.
- Do regular expressions make sense?
- Regular expressions are hard to read and write, double checking these work as expected and think of edge cases that it may not currently cover can help weed out issues early.