Code Review Best Practices For Software Engineers

Summary

In this video, Tom shares key tips for conducting effective and constructive code reviews. He emphasizes the importance of emotional readiness, recommending that reviewers avoid working when stressed or tired. Tom also discusses practical strategies such as using personal checklists, automating simple checks, and understanding the bigger picture of each pull request. He advises offering constructive feedback with clear explanations, recognizing good code solutions, and adapting the review approach based on urgency. The goal is to ensure code reviews are both helpful and respectful, fostering better learning and collaboration in the development process.

Takeaways

• 😀 Don't do code reviews when you're having a bad day. If you're too tired or stressed, let the requester know and postpone the review.
• 😀 Code reviews should not go on for too long. Limit sessions to avoid burnout and maintain empathy throughout the process.
• 😀 Prepare a personal checklist for code reviews to ensure you cover all important areas, such as readability, security, and tests.
• 😀 Always consider platform-specific challenges. For example, in mobile apps, check how the app behaves if the user denies permissions or loses connection.
• 😀 Understand the overall context of the pull request before diving into the details. A solution that seems odd in isolation might make more sense in the broader context.
• 😀 Automate basic checks like linting or syntax validation. This saves time for both the reviewer and the requester by catching easy-to-fix issues early.
• 😀 Evaluate the urgency of the change. For small fixes, prioritize speed; for larger changes, ensure there's enough time for optimization.
• 😀 Provide knowledge-sharing feedback in your reviews. Suggest improvements and solutions to help the requester improve over time.
• 😀 Don’t just mark what’s wrong—explain why something is wrong and suggest how to fix it. This is a valuable learning opportunity for the requester.
• 😀 Recognize and highlight good code. Acknowledge strong solutions to reduce tension and promote a positive review atmosphere.

Q & A

Why is it important not to do code reviews when you're having a bad day?

Code reviews require focus, empathy, and a constructive mindset. When you're stressed, tired, or angry, you're more likely to provide negative feedback or overlook important details, which can harm the review process and make the requester feel personally attacked. It's better to postpone the review until you're in the right frame of mind.

How long should a code review session last, and why?

Code reviews should not be conducted for too long. While starting in a good mood, after a couple of hours, reviewers may lose focus and empathy, which can lead to ineffective or frustrating reviews. Limiting the review time helps maintain quality and effectiveness.

What is the benefit of creating a personal checklist for code reviews?

A personal checklist helps ensure that important elements are consistently reviewed and nothing is overlooked. It allows for a more organized and thorough process tailored to the specific needs of the project or developer.

What specific areas should be considered when reviewing code for mobile projects?

For mobile projects, you should check whether the code handles specific issues like permissions, app interruptions (e.g., when the user leaves the app), or connectivity loss. These are common challenges in mobile development and should be accounted for in the review.

Why is it important to understand the whole idea behind a pull request before reviewing the details?

Understanding the full context of a pull request can help you evaluate the code more accurately. Sometimes, solutions that seem unusual at first make more sense when you see the bigger picture. This prevents misunderstandings and ensures you're providing constructive feedback.

How can automation tools help during code reviews?

Automation tools, like linters and CI/CD pipelines, can catch simple issues such as syntax errors, formatting problems, or failing tests before the review even begins. This saves time for both the reviewer and the requester by addressing these basic issues upfront.

What role does the urgency of a pull request play in the review process?

The urgency of the pull request can influence the approach to the review. If it's a critical hotfix, it may be more important to review and merge quickly, while more complex changes may allow for additional time to optimize the code. Flexibility is key based on the situation.

Why is it important to view a pull request as a learning opportunity for the requester?

Code reviews are not just about identifying issues; they are also an opportunity to share knowledge and help the requester improve. Providing constructive feedback and suggesting better solutions can help the developer grow and write better code in the future.

What should you do if you find a good solution in the code during a review?

It's important to highlight and appreciate good solutions, not just point out mistakes. Recognizing the positives helps maintain a constructive atmosphere and boosts the morale of the requester, fostering a better working relationship.

How can providing constructive feedback in a code review save time in the long run?

By taking the time to explain why something is wrong and offering suggestions for improvement, you help the requester avoid repeating the same mistakes. This leads to more efficient reviews in the future and reduces the time spent on subsequent code corrections.