CSC/ECE 517 Fall 2024 - E2476. Reimplement student teams controller.rb

Introduction

Expertiza is an open-source system built on Ruby on Rails, collaboratively maintained by students and faculty at NC State. This platform gives instructors extensive control over assignments, enabling them to add topics, create assignment groups, and manage peer reviews for various types of coursework. Expertiza is well-equipped to handle submissions across multiple formats, including URLs and wiki pages, and it offers a peer review system that facilitates constructive feedback among students.

A key focus of recent development in Expertiza has been the shift to a client-server architecture, where Ruby on Rails functions as the backend and React is utilized for the frontend. This architectural update requires reworking existing modules into RESTful API endpoints, allowing React components to interact efficiently with the backend. By adopting this approach, Expertiza aims to enhance modularity, performance, and scalability.

Project Description

The project mainly focuses on reimplementing the StudentTeamsController in Expertiza's backend, which is designed for student-facing operations where students participate in teams. This includes actions that directly affect individual team members, such as adding or removing students from teams, viewing team details, and managing their participation.

The TeamsController, on the other hand, is focused on instructor-driven operations that handle high-level team management across different contexts, such as courses and assignments. It manages operations like team creation, deletion, randomization, and bulk management actions.

Problem Statement

The current implementation of the StudentTeamsController in the Expertiza system is overly complex and tightly coupled, leading to difficulties in maintaining and extending the codebase. The controller is responsible for managing student teams in assignments, handling tasks like team creation, editing, management, and the integration of topics in assignments that require team-based decisions. However, it suffers from issues such as:

• Code redundancy and inefficiency due to business logic being embedded directly in the controller.
• Lack of modularity and poor separation of concerns, violating the Single Responsibility Principle (SRP). For example, it also handles the integration with topics when assignments involve choosing topics, complicating the team’s logic.
• Difficult-to-understand methods and tightly coupled logic for handling assignment-specific conditions, such as team-topic associations.
• Poor user feedback that does not provide clear or actionable information after critical operations.

These problems create a system that is hard to scale, maintain, and extend, especially as new features are added. To address these challenges, the goal is to reimplement the StudentTeamsController in the newer Expertiza backend codebase by adhering to object-oriented design principles, specifically focusing on maintainability, scalability, and modularity. The new design will improve the user experience by simplifying controller logic, providing clearer feedback, and ensuring that the system is easier to extend and maintain in the future.

Objectives

The main objective is to migrate the Student Task controller logic from serving HTML responses in the Ruby on Rails MVC model to returning JSON responses as a RESTful API, as part of the backend implementation. While reimplementing the controller, the following considerations will be incorporated to ensure a clean, maintainable, and scalable API:

• Reimplement the controller logic and write methods which appropriately follow the Single Responsibility Principle (SRP).
• Move business logic from the controller to appropriate model classes like Team or AssignmentTeam.
• Ensure all method names clearly describe their purpose and represent actions.
• Reimplement a Prototype pattern for creating mentored teams, leveraging the AssignmentTeam class.
• Automatically generate team names when a team is first referred to unless the user has specified a name when requesting team creation.
• Handle team requirements with better abstraction:
• Try to eliminate direct logic in the controller that checks for specific assignment requirements such as topic handling.
• Rename student_team_requirements_met? to something more descriptive and break it into smaller methods checking individual conditions.
• Aim to decouple topics from this controller entirely, ensuring better abstraction, that can involve changes to other classes or introducing service objects to handle specific requirements.
• Improve feedback to users and ensure that the user receives clear and actionable feedback after operations like team creation, removal of users, and other key actions.
• Add comprehensive comments throughout the controller, clearly explaining the purpose and functionality of custom methods.

Development Strategy

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the student_teams_controller.rb and other related classes such as Team or AssignmentTeam model. We design out test cases and iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes. Additionally, we emphasize on the strict adoption of SRP and DRY principles as per the object-oriented programming conventions. Our goal is to reimplement the existing functionalities In the newly designed back-end foundation to foster a more efficient and organized codebase utilizing newer technologies. This approach will significantly enhance reusability and scalability across all the application while maintaining clean codebase.

Project Design and Implementation

The main approach to be followed throughout this project is to embrace the Prototyping Pattern within the controller while taking into account the current functionalities to be reimplemented within the student_teams_controller.rb that can capitalize its capability to encapsulate distinct controller actions. This strategic implementation aims to ensure seamless extensibility and enhanced usability. By employing this pattern, we establish a structured framework for defining and managing the diverse operations the controller handles, promoting a more organized and manageable code structure.

Functionality

1. Reimplement the Controller to Follow SRP:

• Break down large, complex methods into smaller, focused methods that adhere to the Single Responsibility Principle (SRP).
• Reimplement existing methods and logic while ensuring that each class and method have a clear, well-defined responsibility.
• Move business logic and complex operations out of the controller and into the appropriate model classes (e.g., Team, AssignmentTeam), ensuring the controller only handles HTTP-specific concerns (e.g., request handling, responses).

2. Improve Method Naming and Clarity:

• Ensure all method names are descriptive and represent the intent of the operation (e.g., renaming methods like student_team_requirements_met? to something more specific like validate_topic_requirements_for_team_creation).
• Adopt consistent naming conventions to improve the readability of the codebase.

3. Implement the Prototype Pattern for Team Creation:

• Leverage the Prototype pattern to create mentored teams through the AssignmentTeam class, allowing for easier management and creation of teams with a mentored structure.
• Automatically generate team names when a team is first created, unless a user has specified a custom name to improve the user experience and simplify team management.

4. Abstract Assignment-Specific Logic:

• Move logic related to assignment-specific requirements (e.g., topic handling) away from the controller, reducing complexity and increasing modularity.
• Introduce service objects or model methods to handle specific requirements like topic assignment, thereby decoupling assignment-related logic from the controller.
• Break down the student_team_requirements_met? method into smaller, more specific checks for different requirements (e.g., topic validation, minimum team size, etc.).

5. Improve User Feedback:

• Enhance the clarity and actionability of feedback messages after key operations (e.g., team creation, user removal, etc.).
• Provide users with clear, helpful notifications on the success or failure of their actions, including any necessary next steps or troubleshooting guidance.
• Ensure error handling is robust, and feedback is specific (e.g., specify which conditions were not met when creating or modifying teams).

6. Commenting and Documentation:

• Add comprehensive comments throughout the controller to clearly explain the purpose and functionality of custom methods and refactored logic.
• Ensure that code is well-documented, making it easier for future developers to understand and extend the functionality of the controller.

Testing Plan

We plan to perform comprehensive testing of the student_teams_controller.rb and related classes using RSPEC and leverage FactoryBot to construct the required test fixtures for testing extensive scenarios. Our approach involves reimplementing the existing test cases provided to the older code base and make sure that it is enhanced by covering more test scenarios to minimize code smells. We aim to verify the reimplemented functionality, validate the restructured code in the student_teams_controller.rb and reduce any design or code smell.

Mentor

• Ammana, Sahithi <sammana@ncsu.edu>

Team Members

• Eathamukkala, Akarsh Reddy <aeatham@ncsu.edu>
• Koul, Anmol <akoul2@ncsu.edu>
• More, Harsh Manoj <hmore@ncsu.edu>