Advanced Code Review

Scenario: Design a review strategy for a 50-person development team

1. Create a repository to practice with:

   mkdir review-strategy-demo
   cd review-strategy-demo
   git init
   git remote add origin [your-repo-url]

2. Design review criteria based on change size:

   # Small changes (< 50 lines): 1 reviewer
   # Medium changes (50-200 lines): 2 reviewers  
   # Large changes (> 200 lines): Architecture review required
   # Security-sensitive: Additional security review

3. Document your strategy:

   echo "# Code Review Strategy
   
   ## Review Requirements by Change Size
   - **Small** (< 50 lines): 1 peer reviewer
   - **Medium** (50-200 lines): 2 peer reviewers
   - **Large** (> 200 lines): Architecture review + peer review
   - **Security-sensitive**: Security team review required
   
   ## Automated Gates
   - All tests must pass
   - Code coverage > 80%
   - Linting checks pass
   - Security vulnerability scan clear
   
   ## Review Timeline
   - Reviews should be completed within 24 hours
   - Urgent fixes can bypass some checks with post-review
   - Architecture reviews scheduled weekly
   " > REVIEW_STRATEGY.md
   
   git add REVIEW_STRATEGY.md
   git commit -m "Add enterprise code review strategy"

Scenario: Set up automated quality gates for your repository

1. Create a GitHub Actions workflow:

   mkdir -p .github/workflows
   cat > .github/workflows/pr-checks.yml << 'EOF'
   name: PR Quality Checks
   on:
     pull_request:
       branches: [main]
   
   jobs:
     quality-gates:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v3
           
         - name: Check file size
           run: |
             # Prevent large files
             find . -type f -size +1M -not -path "./.git/*" | tee large_files.txt
             if [ -s large_files.txt ]; then
               echo "Large files detected - review required"
               exit 1
             fi
             
         - name: Check commit messages
           run: |
             # Validate commit message format
             git log --pretty=format:"%s" ${{ github.event.pull_request.base.sha }}..${{ github.sha }} | \
             grep -E "^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .+" || \
             (echo "Invalid commit message format" && exit 1)
             
         - name: Detect secrets
           run: |
             # Simple secret detection
             if grep -r "password\|secret\|key\|token" --include="*.js" --include="*.py" --exclude-dir=.git .; then
               echo "Potential secrets detected - security review required"
               exit 1
             fi
   EOF

2. Add branch protection rules via GitHub CLI:

   # Install GitHub CLI if not available
   # gh auth login
   
   # Set up branch protection
   gh api repos/:owner/:repo/branches/main/protection \
     --method PUT \
     --field required_status_checks='{"strict":true,"contexts":["quality-gates"]}' \
     --field enforce_admins=true \
     --field required_pull_request_reviews='{"required_approving_review_count":2}' \
     --field restrictions=null

3. Test the quality gates:

   git add .github/workflows/pr-checks.yml
   git commit -m "feat: add quality gates workflow"
   git push origin main
   
   # Create test branch with intentional issues
   git checkout -b test-quality-gates
   echo "password=secret123" > config.js
   git add config.js
   git commit -m "bad commit message"
   git push origin test-quality-gates

Scenario: Set up advanced review features for your team

1. Create a CODEOWNERS file:

   mkdir -p .github
   cat > .github/CODEOWNERS << 'EOF'
   # Default owners for everything
   * @your-username
   
   # Specific file patterns
   *.js @frontend-team
   *.py @backend-team
   /docs/ @documentation-team
   /security/ @security-team
   
   # Critical files require multiple approvals
   package.json @your-username @senior-dev
   Dockerfile @your-username @devops-lead
   EOF

2. Create a pull request template:

   cat > .github/pull_request_template.md << 'EOF'
   ## Description
   Brief description of changes and motivation
   
   ## Type of Change
   - [ ] Bug fix (non-breaking change which fixes an issue)
   - [ ] New feature (non-breaking change which adds functionality)
   - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
   - [ ] Documentation update
   
   ## Review Checklist
   - [ ] Code follows style guidelines
   - [ ] Self-review completed
   - [ ] Tests added/updated for changes
   - [ ] Documentation updated if needed
   - [ ] No new security vulnerabilities introduced
   
   ## Testing
   - [ ] Unit tests pass
   - [ ] Integration tests pass
   - [ ] Manual testing completed
   
   ## Related Issues
   Fixes #(issue number)
   EOF

3. Practice advanced review features:

   # Create a test PR to practice on
   git checkout -b advanced-review-demo
   echo "// TODO: Optimize this function
   function calculateTotal(items) {
     var total = 0;
     for(var i = 0; i < items.length; i++) {
       total += items[i].price;
     }
     return total;
   }" > calculation.js
   
   git add .
   git commit -m "feat: add basic calculation function"
   git push origin advanced-review-demo
   
   # Create PR and practice:
   # - Adding line comments
   # - Suggesting specific changes
   # - Using review templates
   # - Testing CODEOWNERS automatic assignment

Scenario: Establish review culture guidelines and metrics

1. Create review guidelines document:

   cat > .github/REVIEW_GUIDELINES.md << 'EOF'
   # Code Review Guidelines
   
   ## Our Review Philosophy
   We believe code reviews are collaborative learning experiences that improve both code quality and team knowledge.
   
   ## Review Principles
   ### For Reviewers
   - **Be Kind**: Focus on code, not the person
   - **Be Specific**: Explain why, not just what
   - **Be Timely**: Reviews should happen within 24 hours
   - **Be Thorough**: Check logic, style, tests, and documentation
   
   ### For Authors
   - **Be Open**: Welcome feedback as learning opportunities
   - **Be Responsive**: Address feedback promptly
   - **Be Descriptive**: Write clear PR descriptions and commit messages
   - **Be Proactive**: Self-review before requesting review
   
   ## Review Checklist
   - [ ] Code is readable and well-structured
   - [ ] Tests cover new functionality
   - [ ] Documentation is updated
   - [ ] Security considerations addressed
   - [ ] Performance implications considered
   - [ ] Error handling is appropriate
   
   ## Escalation Process
   1. Discussion in PR comments
   2. Video call if complex discussion needed
   3. Architecture review for design decisions
   4. Team lead involvement for blocking issues
   EOF

2. Set up review metrics tracking:

   # Create a simple metrics script
   cat > review-metrics.sh << 'EOF'
   #!/bin/bash
   # Basic review metrics collection
   
   echo "=== Review Metrics Report ==="
   echo "Period: Last 30 days"
   echo ""
   
   # Average time to first review
   echo "Average time to first review:"
   gh pr list --state merged --limit 50 --json createdAt,reviews | \
     jq -r '.[] | select(.reviews | length > 0) | 
       (.reviews[0].submittedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)'
   
   # Review participation
   echo "Review participation:"
   gh pr list --state merged --limit 50 --json reviews | \
     jq -r '.[] | .reviews[] | .author.login' | \
     sort | uniq -c | sort -nr
   
   # Average PR size
   echo "Average PR size (lines changed):"
   gh pr list --state merged --limit 50 --json additions,deletions | \
     jq '.[] | .additions + .deletions' | \
     awk '{sum+=$1; count++} END {print sum/count}'
   EOF
   
   chmod +x review-metrics.sh

3. Practice giving constructive feedback:

   # Create a sample PR for practice
   git checkout -b practice-feedback
   echo "function processUser(user) {
     if (user.name) {
       if (user.email) {
         if (user.age > 18) {
           return processAdult(user);
         } else {
           return processMinor(user);
         }
       } else {
         throw 'No email';
       }
     } else {
       throw 'No name';
     }
   }" > user-processor.js
   
   git add user-processor.js
   git commit -m "add user processor"
   git push origin practice-feedback
   
   # Practice reviewing this code:
   # - Identify nested if statements
   # - Suggest early returns
   # - Recommend specific error handling
   # - Propose input validation improvements