Code Review

Code Review Best Practices for the Tech Innovators Network (THiNK)
Streamlined for collaboration, quality, and innovation—built on Git, GitHub, and VSCode workflows.

1. Introduction

Code reviews at THiNK are about catching bugs early, sharing knowledge, and aligning on technical decisions—especially in our mix of ML projects, web apps, and databases. This guide focuses on the review process itself, while version control practices (e.g., commit prefixes, branching) are covered in our Version Control Documentation. Let’s make reviews a conversation, not a chore.

2. Submitting Code for Review

What Authors Need to Do:

1. Open a Pull Request (PR):

   • Use a descriptive title (e.g., “Refactor model training pipeline for scalability”).
   • Link related issues (e.g., Fixes #123) and include testing steps (see Version Control Documentation for commit message templates).

2. Request Review:

   • Tag a colleague—preferably someone outside your immediate team.
   • If reviewing ML code, consider tagging someone with model deployment experience.

3. Stay Responsive:

   • Address feedback within 24 hours of approval.
   • If blocked, ping the reviewer or reassign the PR.

Example PR Template:

# Refactor Model Training Pipeline  

**Goal**: Improve training speed for image classifiers.  

**Changes**:  
- Switched to distributed training.  
- Added monitoring for GPU usage.  

**Testing**:  
- Run `python test_training.py` to validate throughput.  

3. Reviewing Code

What Reviewers Need to Do:

1. Acknowledge Quickly:

   • Respond within 1 hour (e.g., “I’ll review this in 30 mins”).

2. Focus on Impact:

   • Check for security risks, performance bottlenecks, and maintainability.
   • For ML code:
     • Are hyperparameters logged?
     • Is the model versioned?
     • Are deployment steps clear?

3. Use Inline Comments:

   • Flag issues directly (e.g., “This might cause a memory leak—consider using a generator”).

4. Approve or Block:

   • Add a comment like “LGTM after addressing X and Y”.
   • Block merges if tests fail, security risks exist, or CI is red (see Version Control Documentation for CI setup).

Example Review Comment:

Looks solid, but:  
- Line 45: Add error handling for GPU allocation failures.  
- Ensure the model is saved to `models/v1` (see [Versioning Guide](#)).  

4. Best Practices

• Turnaround Time:

  • Reviewers: Aim to complete reviews within 2 business days.
  • Authors: If a reviewer is unresponsive, tag another colleague.

• Knowledge Sharing:

  • Use reviews to teach (e.g., “Did you know about this VSCode extension for model profiling?”).

• Handling Disagreements:

  • If stuck, escalate to a maintainer or open a team discussion.

• ML-Specific Checks:

  • Are training datasets versioned?
  • Is the model tested on edge cases (e.g., rare input formats)?

5. Common Pitfalls to Avoid

• Subjectivity: Focus on objective issues (e.g., “This code is hard to test”), not style debates.
• Ignoring CI: Never merge a PR with failing tests (see Version Control Documentation for CI/CD).
• Overloading PRs: Keep PRs small—split large changes into multiple reviews.

6. Conclusion

Code reviews at THiNK are a chance to learn, teach, and ship better code. By focusing on impact, staying responsive, and leveraging our ML expertise, we keep projects robust and collaborative.

Real-Life Example:
A developer merged a model training script without logging hyperparameters. A reviewer caught it, and the fix prevented a 2-week debugging nightmare.

Let’s keep reviews constructive—every line of feedback matters. 🚀