Peer code review is a process where you ask other developers to examine and comment on your code, usually before merging it to a shared repository. It can help you improve your code quality, learn from others, and catch bugs and errors early. But how can you use peer code review effectively for your code? Here are some tips to make the most of this practice.
Not every developer can give you useful feedback on your code. You should look for reviewers who have relevant expertise, experience, and availability. Ideally, they should be familiar with the project, the language, the framework, and the standards you are using. They should also have enough time and interest to review your code thoroughly and promptly. You can use tools like GitHub or GitLab to assign reviewers automatically or manually, or ask for volunteers.
Ideally, on trusted teams, reviewing a change set is best done by someone synchronously (not asynchronously) who is intimately familiar with the feature domain, the code base and has been involved throughout the code creation process. I am describing a pair in a pair programming approach. This provides a continuous review process between two people in synchronous fashion before it is committed to trunk. In some scenarios eg open source projects, asynchronous code reviews are more appropriate. However, the vast majority of software teams do not work in this context, and crucially would gain far more from pair programming and synchronous working patterns.
Before you submit your code for review, you should make sure it is clear, concise, and consistent. You should follow the coding conventions and style guides of your project, and use meaningful names and comments. You should also run tests, check for errors, and fix any obvious issues. You should provide a descriptive title and summary for your code, and explain the purpose, context, and scope of your changes. You should also highlight any areas where you need specific feedback or help.
Preparing your code for peer review is a crucial step. Start by ensuring your code is clean, well-organized, and follows the project's coding standards. This includes proper formatting, naming conventions, and commenting. Comments should be clear and concise, explaining the rationale behind complex sections of code. It's also important to test your code thoroughly before the review to catch any obvious bugs. Providing a brief overview or documentation of the changes you've made can be incredibly helpful for reviewers. This preparation not only makes the review process more efficient but also demonstrates your professionalism and respect for your peers' time.
A good habit to develop is to review your own code before asking others to do so. This can help you spot and fix any mistakes, typos, or inconsistencies that you might have overlooked. You can use tools like code linters, formatters, or analyzers to automate some of the checks and corrections. You can also use a checklist or a rubric to guide your self-review. You should be honest and critical of your own code, and try to anticipate the questions and comments of the reviewers.
In a world of trunk based development, pair programming and continuous deployment to production: a git push means a deployment to your real end users. Placing the onus on the original authors of the code, scaling up process with size/risk of the change, is one of the most effective ways to reduce waste in a team.
When you receive feedback from the reviewers, you should appreciate their effort and time, and acknowledge their suggestions and critiques. You should not take feedback personally or defensively, but rather as an opportunity to learn and improve. You should address the feedback promptly and politely, and explain how you resolved or incorporated it. You should also ask for clarification or justification if you are unsure or disagree with some of the feedback. You should avoid arguing or ignoring the feedback, unless you have a valid reason.
When you review someone else's code, you should give feedback that is respectful, specific, and helpful. You should focus on the code, not the person, and avoid harsh or vague comments. You should praise what is good, and suggest what can be improved. You should also explain why you are giving feedback, and provide examples or references. You should balance positive and negative feedback, and avoid nitpicking or imposing your preferences. You should also be open to discussion and feedback on your feedback.
Giving feedback respectfully is vital in peer code reviews. Approach the review process with a constructive and collaborative mindset. When suggesting improvements or pointing out issues, be specific and focus on the code, not the coder. Use phrases like 'I suggest...' or 'You might consider...' to convey your points in a supportive, non-confrontational manner. Remember to also highlight what is done well in addition to what could be improved. This balanced approach fosters a positive learning environment and encourages open, productive dialogue. Respectful feedback not only helps in refining the code but also strengthens team relationships and boosts overall morale.
Peer code review is not only a way to check and improve your code, but also a way to learn and grow as a developer. You should reflect on the feedback you receive and give, and identify the strengths and weaknesses of your code and your skills. You should also seek feedback on how you can improve your code review process, and apply the best practices and lessons learned to your future code. You should also share your insights and knowledge with your peers, and foster a culture of collaboration and learning.
Learning from the peer code review process is essential for personal and professional growth. Be open to the feedback you receive, viewing it as an opportunity to improve your coding skills. Pay attention to recurring themes in the feedback, as they can indicate areas where you might need further improvement or study. Additionally, when reviewing others' code, observe and learn from their coding styles, techniques, and problem-solving methods. This two-way learning process enhances your understanding of best practices and broadens your technical knowledge. Embrace the code review process not just as a task, but as a continuous learning journey, integral to becoming a more skilled and versatile developer.
Code reviews and pull requests are not a safe default, and in some cases contribute to holistically decreased code quality. This is because the baseline cost of change, even for a small change, has a fixed cost of a PR review. In my experience, this leads to people not always making small refactorings *as soon as they see them*. Removing the process overhead for these tiny changes can quickly add up to a big impact on holistic code quality (even things like renaming variables and methods). This is because people are unwilling to invest in the total cost of change (including the process overhead of code reviews and a pull request), for small changes.
Effective peer code review is a valuable practice that can enhance code quality and facilitate knowledge sharing within a development team. Here are some best practices for conducting peer code reviews: 1. Set Clear Objectives 2. Keep Reviews Small 3. Choose the Right Reviewers 4. Automate What You Can 5. Provide Context 6. Encourage Collaboration 7. Be Respectful and Constructive 8. Use a Checklist 9. Rotate Reviewers 10. Set Time Limits 11. Follow Up 12. Learn from the Process