📋 Live Session Code Review SOP
📋 Code Review SOPs - Original Sharepoint Document
This SOP ensures that code review sessions are productive, focused, and aligned with team standards. Authors must come prepared to present their work clearly, receive feedback constructively, and contribute to team learning.
🎯 1. Select the Right Code for Review
Choose code that is:
Significant: A meaningful feature, bugfix, refactor, or architectural change.
Appropriately Sized: Not trivial, but also not too large to review effectively.
Stable: Avoid untested or unstable code unless it's a WIP session agreed in advance.
📝 2. Prepare a Review Summary (Mini Deck or Document)
Prepare a concise summary covering (doesn't have to be properly documented):
a. Context / Background
What problem are you solving? What motivated this change?
b. Key Changes
Overview of affected files/modules. Design decisions, libraries, or patterns used. Challenges faced and how they were addressed.
c. Testing
How was the code validated? (unit tests, e2e, manual) Any known edge cases or limitations?
d. Impact
What parts of the system could be affected? Any performance or security considerations?
e. Feedback Areas
Highlight specific areas where feedback is needed (e.g., logic, readability, error handling).
🧹 3. Clean Up Your Codebase
Remove commented-out or debug code. Ensure meaningful naming and documentation. Write or update unit tests for each function (mandatory for both FE and BE). Maintain code readability and structure.
⚙️ 4. Ensure Code is Ready to Run
Set up your environment in advance. Run the app or feature beforehand to avoid surprises. Prepare sample data if needed. Ensure all dependencies are installed and paths are correct.
🗣️ 5. Structure the Live Walkthrough
Suggested Format:
Intro (2–3 mins): Brief overview of the PR/code.
Code Walkthrough (5–10 mins): - Focus on important files and functions. - Avoid line-by-line explanations unless necessary.
Testing/Demo (2–3 mins): Run the code or tests if applicable.
Open Floor (5–10 mins): Invite feedback and questions.
🧠 6. Mindset for the Session
Be open to feedback—even if it challenges your assumptions. Avoid defending every line—focus on learning and improvement. Document feedback and follow-up actions.
👥 7. Team Lead Guidelines & Expectations
PR Submission Timing: PRs must be submitted well in advance. Late PRs (within 1–2 hours of the session) will be deferred to the next session.
PR Size Limits: - FE: Max ~1000 lines of code. - BE: Max ~200-400 lines or 4–5 functions. Provide a summary outlining: - Doctypes created - Functions and their logic - Expected API responses
Daily Code Reviews: 30–40 minute sessions. Team leads will provide time slots.
Review Focus: - BE: Best practices, readability, bugs, optimization, API responses. - FE: Functionality, UI/UX consistency, performance, test coverage.
Review Process: - Junior devs may conduct initial reviews. - Senior devs/team leads will handle final merges. - peer reviews via GitHub comments is encouraged.
Session Format: 30-40-minute slots, 2 devs per session.
Review Style: Concise, focused, and actionable feedback.
📦 Optional Materials to Bring
Link to PR or branch Architecture diagram (if applicable) Code snippets for complex logic
❌ What to Avoid
Unstructured walkthroughs without context Oversized PRs that are hard to review Over-defending personal coding preferences
🔄 Pull Request (PR) Conventions
PR title should always reflect the purpose of it. Title should be short and concise. For example "Fix bug in login feature" or "Add support for dark mode". Every PR should have a details description. Describe the specific changes made, including any new features, bug fixes, or improvements. Use bullet points to break up large blocks of text and make the description easier to read. Request reviews from relevant team members or stakeholders. Respond to feedback and comments from reviewers, and make any necessary changes.
📄 Example PR:
Title: "Fix bug in login feature"
Description:
Fixes a bug in the login feature where users were unable to log in due to an incorrect password validation.
Changes:
- Updated password validation logic to correctly handle special characters
- Added tests to cover the new validation logic
- Updated documentation to reflect the changes
Related issues: #123