Peer code review is where fellow developers within a team review each other's code before it is merged into the main codebase. It involves having one or more team members analyze, evaluate, and provide feedback on the code changes made by their colleagues.

Why Peer Code Review?

Peer code review enhances code quality through error detection, suggestions for improvement, knowledge sharing, collaboration, consistency, and identification of security and performance concerns.

• Error Detection: Different developers may catch errors or bugs that the original coder missed. 4 eyes are always better than 2.
• Code Quality: Reviewers can suggest improvements, optimizations, and best practices that lead to cleaner and more maintainable code.
• Knowledge Sharing: Reviewers and code authors can learn from each other's approaches, techniques, and solutions, improving the overall skillset of the team.
• Collaboration: Code reviews foster collaboration and communication among team members, enhancing the team's cohesiveness.
• Consistency: Code reviews ensure that the codebase adheres to coding standards and follows established conventions.
• Security and Performance: Reviewers can identify potential security vulnerabilities and performance bottlenecks.

How to Conduct Peer Code Review?

• Submit the Code: The developer who made the changes submits the code for review. This could be through a merge request (MR) in version control systems like Git.
• Select Reviewers: Choose one or more team members to review the code. Consider expertise and experience to ensure a comprehensive review.
• Review Process: Reviewers thoroughly examine the code, considering aspects such as correctness, logic, functionality, coding standards, and potential issues.
• Feedback: Reviewers provide feedback through comments on the code changes. Feedback could include positive comments, suggestions for improvement, and pointing out issues.
• Iteration: The original developer addresses the feedback, making necessary changes or providing explanations if needed. The code may go through multiple rounds of review and refinement.
• Approval and Merge: Once the code meets the standards and receives approval from reviewers, it can be merged into the main codebase.
• Learn and Adapt: Both the code author and reviewers should learn from the review process, improving their skills and applying feedback to future work.

Best Practices

• Set Clear Expectations: Define the purpose and scope of the code review. What should reviewers focus on? What are the goals of the review?
• Be Constructive: Feedback should be constructive and respectful. Focus on the code, not the coder.
• Timeliness: Conduct reviews promptly to prevent bottlenecks in the development process.
• Use Tools: Utilize code review tools and platforms to streamline the process and provide a structured environment for discussions.
• Rotate Roles: Rotate the role of code author and reviewer to ensure a balanced exchange of knowledge and viewpoints.
• Documentation: Keep records of reviews and changes for future reference and learning.

Best Strategy

SMART assists us in recalling criteria for directing the establishment of goals and objectives anticipated to yield improved outcomes in project management, employee performance management, and personal development.

• Specific: The goal should focus on a precise enhancement area or address a distinct requirement.
• Measurable: The plan must be quantifiable or permit measurable advancement at the very least.
• Achievable: The goal should be feasible, considering the resources at hand and prevailing limitations.
• Relevant: The goal should harmonize with other business objectives to be deemed valuable.
• Time-bound: The goal must possess a deadline or a defined conclusion.

My Code-Review Checklist ✨

Based on some of the above-mentioned points, I have prepared my own checklist.

• Set Clear Expectations
  • Review the JIRA ticket and familiarize myself with the acceptance criteria. Understand what needs to be done.
  • Next, grasp how the current system operates so you are prepared for the outcomes of the new code alteration.
  • Refer to the document and recollect the discussions concerning the requirement.
• Code Readability: Read through the code to see that everything makes sense
• Code Styling: Has the code been correctly linted? Are style changes committed separately or combined with other changes?
• Code Well-Documented: All methods have PHPDoc with correct parameters. Annotations are used correctly.
• Clean Code: Check all hints in PHPStorm (non-existent classes, variables, properties, unused 'use' statements, etc.)
• Commit History: The commit history is as clean as possible
• Dig-Deep: All acceptance criteria are fulfilled.
• Code Quality:
  • Basic principles like KISS, DRY, YAGNI, or SOLID.
  • Try to see any anti-pattern in the newly added code
  • The proper data access layer for the appropriate codebase has been used
  • Consistent naming patterns are used in the codebase and platform
  • Code is written keeping the performance perspective in mind (like avoiding SQL queries in a foreach loop, etc.)
• Tests/Validate the Code:
  • Proper system/unit tests to test the code should be written
  • Behaviour tests for entire features (If required)
  • Test the feature in a client
  • Check the feature in Postman to verify the correct response format/structure.

Wrap-Up!

Peer code reviews contribute significantly to code quality, team collaboration, and individual growth. By promoting open communication, sharing knowledge, and refining coding practices, they help create more reliable and maintainable software products.