Taking Your First Steps in Code Reviewing
When I first started working after graduation, I didn’t do any code reviews. I felt like I didn’t know enough to provide useful feedback. However, I later realized that I was expected to review code, so I began approving changes without really understanding them. This led to some bugs making their way into production, and I even had a colleague ask why I approved their code. Here’s how you can avoid making these same mistakes.
Understand Your Audience
Think of code as something that’s read by two groups of people: the machines that run it and the programmers who work on it. Code reviews are how we make sure the code works well for both. Knowing this helps us know what to look for when reviewing code.
For programmers, we want the code to be easy to understand and modify. This means the code should make sense on its own. If you see overly complex code, suggest ways to simplify it. If simplification isn’t possible, you can recommend adding comments to explain it. Also, provide feedback to reduce unnecessary connections between different parts of the code and break down large functions into smaller ones. Modular code is easier to work with. Lastly, ensure the code follows a consistent style to make it more readable. If your team doesn’t use an automated style checker, pay attention to common patterns, spacing, and naming conventions.
For machines, we want to ensure that the code does what it’s supposed to and that tests confirm its correctness. When reviewing code, start by understanding the purpose of the changes. If it’s unclear, don’t hesitate to ask the author for clarification. Code isn’t the only thing you should evaluate; also, check the ‘test plan’ to see how the author has proven that the code works and stays that way. This is a critical part of the review.
Dry Run Code Review: A Safe Way to Learn and Improve
Getting into code reviewing might feel overwhelming, especially if you’re new and don’t have much experience. It’s perfectly fine not to grasp everything in the code right away. To begin, think of it like this: it’s like reading a book you don’t fully understand at first.
Imagine you’re reading a book you’ve never read before. You can go through it, ask questions about parts you find confusing, and discuss it with others who’ve read it too. This helps you learn more about the book’s story and characters. It’s the same with code reviewing.
So, when you’re new to code review, you can do what’s called a ‘dry-run’ review. It means you read the code, just like you would with a book, and if there’s something you don’t understand, you ask questions. But here’s the important part: don’t give it your final approval unless you’re completely sure it’s good. This way, you’re learning and providing helpful feedback without causing any problems. It’s like getting to know the story of the code step by step.
As you get more experience with code reviews, here are some tips to get even better at it.
- Look for Better Ways: Imagine you’re a coach for a soccer team. When reviewing code, think like a coach and consider if there’s a better strategy to win the game (or in this case, achieve the same result). Sometimes, there’s a smarter play or approach.
- Prioritize Like a Chef: Think of code like a chef thinks of ingredients. Some ingredients are critical for a dish, while others are just for garnish. Similarly, some parts of the code are super important (like the heart of a recipe), and you should review them very carefully. But for other parts, it’s like checking that you have enough salt — important, but not as critical.
- Label Your Thoughts: Imagine you’re a teacher grading homework. You’d mark some mistakes as ‘must fix’ and others as ‘nice to have.’ In code reviews, you can do something similar by labeling your comments. This helps everyone know which comments need more attention and which are just little suggestions.”
It can be tempting to be a bit lazy with code reviews and quickly say ‘okay’ without really checking. But think of it like this: Imagine you’re a chef in a restaurant, and you’re in charge of making sure every dish is perfect before it goes to the customer.
If you start to let things slide and send out dishes without double-checking, the customers won’t be happy, and the quality of the restaurant’s food will go down. But if you always take that extra minute to make sure everything is just right, you set a great example for the rest of the kitchen staff. They’ll see you care about quality, and they’ll want to do their best too.
In the world of coding, it’s the same. When you review code carefully and make sure it’s well-tested and high quality, you’re like the chef who cares about every dish. You’re showing your team that quality matters, and you’re helping everyone get better.
In summary, advocating for high-quality code is our recipe for making our team truly exceptional.
What were your learnings during the code reviews? Tell me in the comments!
