Code Review

Why Code Review Enables Passive Growth

Code Review is one of the most natural forms of passive growth. Everyone writes code and submits PRs every day, and in the process:

• The reviewee: Gets feedback from more experienced people and learns better implementation approaches
• The reviewer: Sees different perspectives and coding styles, broadening their own horizons
• The whole team: Code style converges toward consistency, and quality continuously improves

How to Implement

Basic Rules

• All code must be reviewed by at least one person before merging
• PRs should be small and focused — one PR does one thing
• Reviews should be completed within 24 hours to avoid blocking

Review Focus Areas

• Correctness: Is the logic correct? Are edge cases handled?
• Readability: Are names clear? Is the structure easy to understand?
• Design: Are abstractions reasonable? Over-engineered or under-designed?
• Performance: Are there obvious performance issues?
• Security: Are there security vulnerabilities?

Review Attitude

• Focus on the code, not the person — discuss the code, not who wrote it
• When suggesting changes, explain why — don't just say "change it to this"
• Mark non-essential improvements as "Nit" or "Optional"
• Acknowledge good code — don't only point out problems

Onboarding New Members

• New members' PRs should be reviewed by experienced members, with extra explanation of the reasoning
• Encourage new members to review others' code as well — they learn by reading code
• In the early stage, pair new members with senior members for review sessions