What should we do for code review?
Published in
5 min readFeb 20, 2024
1. Standards
- Developers might come up with lots of conflicts with each other because of the non-standard policies.
- Each developer can think differently from others. Thus, you should build a roof to gather all the staff.
The easiest way to start is to read the best practice documents that belong to the language or framework you used.
2. Test & CI Mechanism
- Before you start the code review, all test cases should be passed, and the new codes should not crash the existing system.
- Otherwise, you may save your hours on the not-working codes.
The easiest way to solve this problem is to start writing tests and implement some CI/CD pipelines like GitHub Actions, AWS Pipeline, CircleCI, and so on.
3. Responsibilities
- Who should take more responsibility after a bug occurs?
- The Developer who writes that code? Who is the developer who reviews and approves the code?
- Answer: Responsibility should be equal for both of them.
- We are human, and we make mistakes. Thus, it is your team’s code after you open the pull request.
It would be an excellent reading for you:
Mainly, look at the “You are not your code” section.
4. Better Messages
- You can’t review a code without understanding the content. Developers who will review the code should understand the commits and pull request explanations.
You can set a pull request template:
Or you can define some standards for your commits:
5. Keep it small
- Understanding the content, reviewing the code, and finding improvements for big pull requests is tough. Thus, commits and pull requests should be as small as possible.
6. Review by yourself
- You should be inhumane to your code and review yourself before you push it. It will help you and your teammates greatly because sometimes we miss some typos, and waiting for other developers’ reviews for these minor flaws wastes our time.
If you have to open a crowded pull request, send a meeting to your teammates, share your screen, and explain it. It sounds so smooth :)
7. Selection of the reviewers
- It would help if you didn’t wait for all team members’ reviews. Max 2–3 reviewers is enough.
- You can choose a strategy to assign reviewers. You can open a pull request and assign random reviewers to your organization or team. Also, you can select manually. It depends on you.
8. Checklist
- Having a checklist can make your job easier
You can start from here:
9. Egoless Programming & Be kind
- Don’t be “the guy in the room.” Don’t be the guy coding in the dark office, emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
- No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask.
- Critique code instead of people — be kind to the coder, not to the code. Make all your comments positive and oriented to improving the code as much as possible.
I strongly advise you to check this article:
10. Support your ideas with arguments
“Sell your ideas like people sell products.”
- Collect code snippets, links, tutorials, and any resource explaining your comment or idea.
- Show your idea in all aspects. Then, discussing and comparing different choices/ideas will be easier.
