Code Review

Your PR is marked ready for review. Now comes the code review process: first reviewing your own code, then requesting reviews from the team.

Self-review catches the obvious issues before others look at your work. It's respectful of your teammates' time and helps you learn to spot patterns in your own code. After that, external reviews bring fresh perspectives and catch things you might have missed.

💡 Quick tip: Use /unio-code-review to get a structured, educational review of your changes. It checks security, performance, patterns, testing, and creates a detailed review document. See the Cursor AI Commands page for details.

Before Requesting Review

Make sure the basics are covered:

• All tests pass locally
• No linter errors
• Code is self-documented or commented where needed
• PR description is complete and accurate
• You've pushed all commits

Self-Review Checklist

Use GitHub's review feature to go through your own code. Look at the diff file by file, as if you're seeing it for the first time.

💡 Pro tip: Install the GitHub Pull Requests extension to review PR changes directly in VS Code with in-editor commenting and easy navigation between files.

Code Quality:

• Is the code doing what it should?
• Any obvious bugs or edge cases missed?
• Is it readable? Would someone else understand it?
• Are variable and function names clear?

Testing:

• Do the tests cover the important cases?
• Any edge cases that need tests?
• Do all tests pass?

Performance:

• Any obvious performance issues?
• Are database queries efficient?
• Any unnecessary loops or operations?

Security:

• Any security implications?
• Is user input properly validated?
• Are secrets properly handled?

Documentation:

• Is the code self-explanatory?
• Are complex parts commented?
• Does the PR description explain why you made these changes?

Architecture:

• Does this fit with the overall system design?
• Are you using established patterns and tooling?
• Are we creating tech debt?
• Would this make sense to someone new to the codebase?

Addressing Your Own Feedback

If you find issues during self-review, fix them. Add commits addressing the problems, push them, and review again.

Don't be afraid to catch your own mistakes. That's exactly what self-review is for.

Requesting External Review

After completing your self-review, request reviews from your teammates. This brings fresh eyes to your code and helps catch issues you might have missed.

How to request a review:

# Request review from specific teammates
gh pr edit --add-reviewer username1,username2

# Or add reviewers through GitHub's web interface

Who to request:

• Team members familiar with the area you're working in
• Someone who will benefit from understanding the changes
• For significant changes, request reviews from senior team members

What reviewers look for:

• Logic errors and edge cases
• Better approaches or patterns
• Security concerns
• Performance issues
• Maintainability and readability
• Alignment with project standards

Responding to feedback:

• Address feedback promptly
• Ask questions if you don't understand the suggestion
• Push additional commits to address issues
• Mark conversations as resolved once addressed
• Thank reviewers for their time and insights

Once reviews are complete and approved, it's time to merge. Let's move to the next section.