Weekly Team Code Review

This week, you will spend approximately one hour reviewing your teammates' final project code and providing constructive feedback. Code review is a collaborative process that helps teams maintain quality, share knowledge, and ensure everyone stays on track toward successful project completion.

Your goal is to help your teammates succeed by identifying areas for improvement, recognizing good practices, and ensuring projects are progressing appropriately. You can approach this flexibly: conduct a general review of everyone's progress, or focus deeply on one or two teammates who need more support. The key is meaningful engagement that helps your team move forward together.

What to Look For

When reviewing your teammates' MVC Express applications, focus on both code organization and progress momentum. Your reviews should balance technical quality with project advancement, always keeping in mind that you are here to help, not to criticize.

MVC Architecture and Organization

Verify that the application follows proper MVC separation of concerns. Controllers should handle request and response logic without containing business rules or data structures. Models should manage data and business logic independently of HTTP concerns. Views should focus on presentation without embedded business logic.

Check that files are organized logically within the src/ directory structure. Controllers belong in src/controllers/, models in src/models/, middleware in src/middleware/, and views in src/views/. Route configuration should be centralized and clean, typically in a routes file that imports controller functions.

Naming Conventions and Code Quality

File names should clearly indicate their purpose and follow consistent naming patterns. Controller files should match their domain area, model files should represent data entities, and view files should correspond to the pages they render. Variable and function names should be descriptive and follow JavaScript conventions.

Look for common issues like unused parameters in route handlers, inconsistent error handling, hardcoded data in controllers that belongs in models, or missing input validation. Watch for route handlers that do too much work instead of delegating to models and services.

Project Progress and Momentum

Beyond code quality, assess whether projects are moving forward appropriately. Are new features being added? Are previous issues being addressed? Is the project scope still realistic? If a teammate seems stuck or is not making progress, that is exactly when your collaborative review becomes most valuable.

Notice both problems and successes. When you see well-organized code, clever solutions, or good documentation, acknowledge it. When you spot issues or potential roadblocks, offer specific suggestions and resources that can help your teammate move forward.

Review Approaches

You have flexibility in how you conduct your reviews. Choose an approach that makes sense based on your team's current situation and needs.

General Team Review

Spend 10 to 15 minutes with each teammate's repository, examining their overall project structure, recent commits, and code organization. This approach works well when everyone is making steady progress and you want to ensure the whole team maintains good practices. Focus on high-level architecture and identifying any emerging patterns or issues across the team.

Focused Deep Dive

Alternatively, conduct brief check-ins with most teammates and spend 30 to 40 minutes deeply reviewing one or two projects that need more attention. This approach is valuable when a teammate is struggling, implementing a complex feature, or could benefit from detailed feedback. Examine specific files, trace logic through controllers and models, and provide comprehensive suggestions.

Hybrid Approach

Combine both strategies by doing quick progress checks on everyone while identifying who needs deeper support. This balanced approach ensures no one is overlooked while still providing substantial help where it is most needed.

Providing Effective Feedback

Your feedback should be helpful, specific, and encouraging. Remember that you are collaborating with teammates, not evaluating their worth as developers. Everyone learns at different paces and faces different challenges.

Be Specific and Actionable

Instead of saying "your code is messy," identify the specific issue: "The user controller contains data that should be in the user model. Moving the user data object to src/models/user.js would improve separation of concerns." Point to particular files, functions, or patterns so your teammate knows exactly what to address.

Explain the Why

Help your teammates understand the reasoning behind your suggestions. Explain how proper MVC separation makes code easier to test and maintain, or how descriptive variable names help future developers understand the code quickly. When teammates understand the principles behind best practices, they can apply them independently.

Recognize Good Work

Point out what your teammates are doing well. If someone has clean controller separation, acknowledge it. If error handling is thorough, mention that. Positive feedback reinforces good practices and helps teammates know they are on the right track.

Offer Help and Resources

When you identify issues, consider offering to pair program, sharing relevant documentation, or pointing to similar problems you have solved. If a teammate seems stuck, your offer to help troubleshoot together can make the difference between frustration and breakthrough.

Create GitHub Issues When Appropriate

For significant technical issues or improvements, consider creating GitHub issues in your teammate's repository. This provides a clear record of feedback and makes it easier for them to track what needs attention. Keep issues focused and constructive, framing them as collaborative suggestions rather than criticisms.

Common MVC Issues to Watch For

These are frequent problems in MVC Express applications. Helping your teammates recognize and fix these issues will strengthen everyone's understanding.

Controllers Doing Too Much

Controllers should be thin, handling HTTP concerns like parsing requests and sending responses while delegating business logic to models. Watch for controllers that contain data structures, validation logic, or complex calculations. These responsibilities belong in the model layer.

        // ❌ Controller contains business logic and data
        export const getProduct = (req, res) => {
            const products = {
                '1': { name: 'Widget', price: 19.99 },
                '2': { name: 'Gadget', price: 29.99 }
            };
            
            const product = products[req.params.id];
            if (!product) {
                return res.status(404).send('Not found');
            }
            
            // Price calculation in controller
            const discountedPrice = product.price * 0.9;
            
            res.render('product', { product, discountedPrice });
        };

        // ✅ Controller delegates to model
        import { getProductById, calculateDiscountPrice } from '../models/product.js';

        export const getProduct = (req, res) => {
            const product = getProductById(req.params.id);
            
            if (!product) {
                return res.status(404).render('404', { message: 'Product not found' });
            }
            
            const discountedPrice = calculateDiscountPrice(product.price);
            
            res.render('product', { product, discountedPrice });
        };
    

Poor File Organization

Files should be organized by feature or domain, not by type alone. Instead of one massive controllers.js file, separate controllers by their domain area. The same applies to models and routes.

        # ❌ Poor organization
        src/
        ├── controllers/
        │   └── controllers.js    # Everything in one file
        ├── models/
        │   └── data.js           # Generic naming
        └── routes.js

        # ✅ Better organization
        src/
        ├── controllers/
        │   ├── products/
        │   │   └── products.js
        │   ├── users/
        │   │   └── users.js
        │   └── index.js
        ├── models/
        │   ├── products/
        │   │   └── products.js
        │   └── users/
        │       └── users.js
        └── routes/
            └── index.js
    

Inconsistent or Unclear Naming

Variable and function names should clearly indicate their purpose. Avoid single-letter variables, ambiguous abbreviations, or generic names like data or handler. Function names should use verbs that describe what they do.

        // ❌ Poor naming
        const p = getP(req.params.id);
        const d = calcD(p.price);

        // ✅ Clear naming
        const product = getProductById(req.params.id);
        const discountedPrice = calculateDiscountPrice(product.price);
    

Missing Error Handling

Applications should handle errors gracefully rather than crashing or displaying confusing messages. Check that database operations, file system access, and external API calls include proper error handling. Users should receive helpful feedback when something goes wrong.

Assignment Instructions

Complete your weekly code review by following these steps. Remember that the goal is collaboration and mutual support, not finding fault with your teammates' work.

1. Access Teammate Repositories

Get GitHub repository URLs from your teammates. You should have access to at least two or three repositories to review. If you encounter access issues, contact your teammates to ensure repository permissions are set correctly.

2. Conduct Your Review

Spend approximately one hour reviewing your teammates' projects. You can divide this time evenly among all teammates or focus more deeply on those who need additional support. Navigate through their code using GitHub's web interface, examining project structure, recent commits, and code organization.

Pay attention to MVC architecture, naming conventions, file organization, and overall project progress. Take screenshots of particularly good implementations or areas that need improvement. These visual examples will help you provide clearer feedback in your documentation.

3. Provide Feedback

When you find significant issues or have suggestions for improvement, consider creating GitHub issues in your teammate's repository. Keep your issues constructive and specific, explaining both what needs attention and why it matters. For smaller observations or general encouragement, you can share feedback through your team's communication channels.

4. Document Your Review

Complete the submission form below, documenting the teammates you reviewed, the areas you examined, and your key observations. Include screenshots where they help illustrate your points. Be thorough but honest in your documentation as this helps your instructor understand team dynamics and identify where additional support might be needed.

Assignment Submission

Use the form below to document your weekly code review. Fill in the details for each teammate you reviewed, upload relevant screenshots, and provide thoughtful observations about your team's progress. Once complete, download the PDF and submit it to Canvas.

Key Concepts Summary

This weekly review process builds essential professional development skills. You learned to evaluate MVC architecture systematically, provide constructive technical feedback, and support teammates in maintaining code quality while making steady progress on their projects.

Regular code review creates a culture of continuous improvement and shared learning. By examining different approaches to similar problems, you expand your own technical understanding while helping ensure your entire team succeeds. The collaborative nature of this process mirrors professional development environments where peer review and knowledge sharing are fundamental to team success.