Code reviews are not a new concept. They are often used as a manual door check for code changes before merging them with the branch branch. This helps ensure quality and security by preventing developers from working in a vacuum. It can also help ensure that the whole team is aware of what is going on in their project. As with everything related to technology, there are many ways to implement code reviews, and there may be some confusion about how to do code reviews and the goals of a code review.
Code reviews are a chance for you, the committer, and your peers to have a conversation about the changes being made before they are merged to the trunk branch.
I have been privy to a solution for this issue that I still use today and recommend to all developers of every level: comment tagging.
That solution was to start tagging comments in the pull requests using the tags: comment, question, blocker, and recommended.
It would look something like:
[comment] I think you meant to use the forEach prototype method here instead of map.
[blocker] This constructor is too large and should be broken up into individual, specialized methods.
[question] Is this method needed in this class with the merging of feature X? Feature x makes this a global utility method.
[recommended] You could add a test case here to check for negative outcomes. This would help ensure future code changes do not break our expectations.