Code Peer Review (PR), rules and advantages

Before discussing about PR review and its advantages, let's talk about how usually developers react on review comments

• Well, those are just Code Beautification remarks
• Those Static Code Analysis warnings will be caught by MISRA, I fix them later
• Unit test coverage? will do that later !
• etc...

Well that's exactly why PR review process exists in first place.

Peer Review (PR)

PR is a process to help developers to find possible bugs(if any) in advance, making sure all developers practice good/clean coding practices, good code documentation

Process is okay, But whose responsibility is PR review before pushing code to master/release branch ?

In My experience, an Architect/Technical lead should a mandatory reviewer for a PR along with one or more other developer/s in the team. At least 2 people should be reviewing a PR

If more people are reviewing PR more suggestions given, this will help everyone including developer and reviewers. Architect may focus on architecture, design and other developers can look into coding guidelines/practices, code optimizations etc...

Good Practices to follow for PR

• Start with a good commit message (title) , I often observed that commit messages are not self explanatory, confusing
• Self Check with coding guidelines, code formatting, clean code practices
• Less/Few files modifications, if more files are modified its difficult to review and context will be lost.
• No Technical Debt, try to make sure there is no technical debt (avoid)
• Modify/Add unit tests, update unit test files for the modifications and UT coverage
• DoD (Definition of Done), as per you project rules

Here are few good reads on PR

https://blog.codebeat.co/how-to-set-up-an-effective-code-review-b9a9f98d1800

https://github.com/thoughtbot/guides/tree/master/code-review

https://www.kenneth-truyers.net/2018/11/01/best-practices-good-pr/