Member-only story
How to Become a High-Quality Code Reviewer
Here’s what you should do for a quality code review
Code review stops bugs. Stops them early. Stops them before production.
Formal code reviews are hands-on. You know formal ones. You pull up a chair. Start reviewing your school project with a team member. Everything is communicated right on the spot.
Nowadays, we use lightweight, informal code review processes which don’t have the same effect. The quality of code reviews has reduced.
There is a relationship between code review participation and post-release bugs². Code reviewer’s expertise and involvement play a role in the process.
With all this laid out, it is more than clear we need quality code reviews. What can you do to improve your code review process?
Raise PR early
The cost of reworking errors in programs becomes higher the later they are reworked in the process, so every attempt should be made to find and fix errors as early in the process as possible. — Fagan³
Get feedback as soon as possible. This will bring new ideas to the table. Reveal bottlenecks in the code. One could propose a new approach or an existing solution.
Be open to critics. Valuable critics, targeting code, should be accepted. Receive feedback, learn more about the context, and improve.
You should look into your own PR. Look at code in-depth, even after you’ve raised PR. You missed reverting something, or something doesn’t fit well.
Secrets in the code, which shouldn’t be there. This is common. Look at https://www.shhgit.com/. You can see stats, so many secrets are pushed to public repos.
You should label your PR¹. Mark it as WIP. Meaning code is new and converging to a final version.
Working in Bitbucket, we leave tasks for WIP. “Don’t merge” is the task. Github has draft PRs, use them if you can.
