Code reviews, also known as peer reviews, help developers improve code quality and share knowledge before merging and shipping it.
It looks like quality control for software development. They help catch bugs, ensure consistency, and improve code quality. But how we make them more effective?
Part 1: Code Reviews Strategies
A: What to Look for Code Reviews
There are basic code review checklists.
- Am I able to understand the code easily?
- Is the code written following the coding standards/guidelines?
- Is the same code duplicated more than twice?
- Can I unit test / debug the code easily to find the root cause?
- Is this function or class too big? If yes, does the function or class have too many responsibilities?
B: Let’s Automated Tools do boring Parts
Automation helps you make more meaningful contributions as a reviewer. When you can ignore a whole class of issues, such as
- ordering of
importsor naming conventions for source filename
- white spaces
- matches code style guide
it allows you to focus on more interesting things like functional errors or weaknesses in readability.
C: How to argue with a style guide
To avoid disagreements during code reviews, it's helpful to create a style guide that outlines consistent conventions. The guide should include guidelines for naming conventions, whitespace usage, and programming language features. Be sure to update the guide as needed to prevent recurring discussions.
Part 2: Focusing a ChangeList (CL) in Review
A: Navigating a CL in Review
When you are checking multiple files of code,
- Start by giving a detailed summary and talking clearly to others.
- If you have difference opinions, give helpful ideas in a polite way.
- Think about making your team’s way of working better to reduce arguments.
- Focus on finding and fixing important design problems as soon as possible.
B: Efficiency in Code Review
Why prioritize fast code reviews?
In working space, slow code reviews lead to:
- Team delays.
- Developer frustration.
- Compromised code quality.
Please do these ways for code review
- Code reviews should ideally take a day, with reviewers responding within one business day.
- Avoid interrupting coding tasks for reviews; wait for a break.
- stop nitpicking too much and write Nitpicking commands as less as possible
- Quick Response
- When Handling Large CLs, split large changes or give high-level feedback.
C: Effective Communication with your coworker
Respectful and constructive code review feedback is the basis for positive collaboration.
If we are Preciseness > Compassion for code review feedback, we pat ourselves on the back because of our brevity and preciseness. By — Dr. Michaela Greiler
In the past, I often saw reviewing code just like “This is an error, remove this” and “ Why do you use the wrong naming in this”.
But that’s not the right way to build relationships and collaborate with your peers during a pull request. Comments like this contribute to a harsh code review feedback culture and can lead to toxic work environments.
So, before you start a code review, make sure you take the time to carefully phrase our code review feedback.
Think about you aren’t giving instructions to a computer , you are communicating with other human beings.
D: Summerize and Approve
After checking, summarize the important points and approve the changes if they are good. Don’t worry about being perfect, just try to make progress.
- Summarize Key Points — Shorten the main points of the code review. What were the problems and suggestions?
- Approve with Caution — If everything is good and problems are fixed, say yes. Remember, try to make progress, not be perfect.
- Feedback Loop — If there are still problems, talk to the team. The goal is to work together to improve.
Code Review is just like the secret sauce of software development. They are very important. But remember, not all code reviews are perfect. We’ve learned that by focusing on a few important things, we can make them count.
- Functionality, Maintainability, and Security — Think of these as the three (long supporting declarations / critical components) that hold our code. They are the basis. If we keep/make sure our code is functional, easy to maintain, and secure, we’re off to a good start.
- Checklist — Having a checklist is like having a map on a road trip. It keeps us on track and helps us not miss important things during code review.
- Effective Communication — It is the glue that holds our team together. When we communicate well during code reviews, we learn, teach, and grow.
- Continuous Learning — We’re not just here to do code reviews; We are here to improve. Every review is an opportunity to learn something new.
Thank you for joining me today. Keep reviewing, keep learning, and keep coding!
How to Do Code Reviews Like a Human (Part One)
Lately, I've been reading articles about best practices for code reviews. I notice that these articles focus on finding…
Code Review Checklist - To Perform Effective Code Reviews - Evoke Technologies
This blog serves as a great starting point for code reviewers by exploring code review checklist. Helping code…