CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback response map.rb

This page contains the details of OSS project E2509: Reimplement feedback response map done for Expertiza in Spring 2025.

Expertiza and Project Overview

Background

Expertiza is an open-source application used in CSC 517 (Object Oriented Design and Development) as a platform for creating teams, assigning programs, and reviewing submissions, among other tasks. Expertiza is also used to help students develop a working application in order to mimic how students will work on programs in the workplace.

Project Overview

The aim of this project is to implement the feedback_response_map.rb file in the reimplementation-backend repository of Expertiza. Within Expertiza, when a user submits a review, an instance of the Response class is created, associated with a ResponseMap. When a user writes and submits a review in Expertiza, an instance of Response class is created and associated with a ResponseMap. Every ResponseMap connects the reviewed item (reviewed_object_id), the reviewer (reviewer_id), and the reviewee (reviewee_id). Feedback provided by the reviewee on their received review is represented by FeedbackResponseMap, a subclass of ResponseMap. This subclass ensures that the reviewee's comments are appropriately linked to their reviews.

There is room for improvement in the current system and refactoring the FeedbackResponseMap could enhance its efficiency and flexibility. This would allow for better management of feedback data and provide opportunities for optimizing the overall functionality of the review process.

Current Implementation

The current feedback_response_map.rb in the Expertiza repository has several methods including assignment, show_review, get_title, questionnaire, feedback_response_report, and email. The assignment method retrieves the assignment associated with the review, the show_review method returns the review's content as HTML or a message if no review exists, the get_title method returns a simple label and the questionnaire method retrieves the feedback questionnaire associated with the assignment. The feedback_response_report method compiles a report by querying multiple tables to gather reviewer information and responses, handling varying rubrics by round, specifically for three rounds of review. Finally, the email method sends feedback emails to reviewers.

However, there are a few problems in the model that need to be fixed -

• Violation of SOLID and DRY principles: The existing code leads to repetition and complexity, which violates the SOLID and DRY principles.
• Issues with the feedback_response_report methods: This method is complicated, handling only the first three rounds of reviews, which introduces redundancy. It also uses a hardcoded approach to varying rubrics across rounds, which should be generalized to support any number of rounds dynamically.
• Misplaced Responsibilities: The email method should not be placed in this class as it violates the Single Responsibility Principle (SRP). It would be better to create a separate class to handle this method.
• Memory Inefficiencies: The method currently consumes excessive memory by using multiple separate arrays for storing review data for different rounds.
• Code Readability and Efficiency: The code suffers from redundant methods, unclear variable names, and inefficient loops that contribute to poor readability and performance. By eliminating this, the code would become more readable, and maintainable.

Objectives & Requirements

1. Implement methods for the feedback_response_map model

Develop methods in feedback_response_map.rb to properly manage feedback responses and ensure seamless integration and functionality within the system.

2. Adhere to SOLID and DRY Principles

Follow best software design practices by ensuring the code is modular, maintainable, and reusable. Eliminate redundancy and ensure adherence to SOLID and DRY principles.

3. Refactor feedback_response_report Method

Change the feedback_response_report method to allow it to support a dynamic number of rounds and eliminate redundant logic for varying rubrics across rounds, which will improve efficiency.

4. Separate Email Functionality

Separate the email notification logic from the FeedbackResponseMap class using the Visitor Pattern, adhering to the Single Responsibility Principle and enhancing modularity and maintaining clear separation of concerns.

5. Remove Redundant Code and Improve Readability

Eliminate unnecessary methods that do not contribute to core functionality. Refactor long or unclear method names for better clarity, and add detailed comments to explain complex logic for easier maintenance.

6. Testing and Documentation

Implement thorough testing for the new functionality and refactoring. Ensure that the code is well-documented, with clear explanations of logic, method functionality, and expected behavior for future maintainability.

Design

Design Principles

• Solid Principles: We adhered to SOLID principles (specifically Single Responsibility Principle) by ensuring each class has a single responsibility, extending functionality without modifying existing code, substituting derived classes seamlessly, segregating interfaces for specific client needs, and inverting dependencies to rely on abstractions.
• Don’t Repeat Yourself (DRY): Eliminate redundancy by creating general solutions that handle multiple scenarios.
• Visitor Pattern: Utilize this pattern to separate emailing functionality from the main FeedbackResponseMap class.

Implementation Plan

The refactoring will proceed as follows:

1. Implement Feedback Response Map Methods

• Design and implement methods that effectively handles all aspects of the feedback responses.
• Ensure seamless integration with related models, such as ResponseMap, for consistent and accurate feedback management.
• Methods should handle feedback collection, presentation, and reporting appropriately.

2. Refactor the feedback_response_report Method

• Remove the hardcoded logic for the rounds of reviews with a dynamic approach that is able to handle any number of rounds. This could be done using a loop or a grouping mechanism that can adapt to any number of review rounds.
• Replace redundancy with a generalized solution that dynamically adapts to varying rubrics without requiring manual intervention.
• Improve the data structure used by using more flexible and memory-efficient options to reduce memory usage and improve scalability.

3. Separate Email Functionality Using the Visitor Pattern

• Implement the Visitor Pattern to move email handling out of the FeedbackResponseMap class, ideally into a a separate service object.
• Ensure that the new email class follows SOLID principles, especially the Single Responsibility Principle (SRP).

4. Remove Redundant Code

• Review the class for redundant methods and comments.
• Remove any code that is not required for the feedback response management, such as unused helper methods or unnecessary variable assignments.
• Refactor code that repeats functionality found elsewhere in the system to avoid duplication.

Implementation

1. Implement Feedback Response Map Methods

The original feedback_response_map model used inconsistent naming, such as get_title, and retrieved data inefficiently. Additionally, the questionnaire method searched for a questionnaire type rather than using the ActiveRecord associations. The contributor method accessed the reviewee indirectly instead of using direct associations.

The refactored code addressed these issues by improving naming consistency, optimizing data retrieval, and simplifying method logic. To improve naming and align with Ruby naming conventions, get_title was changed to title. The questionnaire method now directly retrieves the assignment’s associated questionnaires using self.assignment.questionnaires, making the code more concise, and the contributor method now directly returns self.reviewee, eliminating unnecessary lookups. These changes improve readability by making method names more intuitive and increase efficiency by reducing redundant database queries and method calls. They also enhance maintainability by providing clearer method definitions, reducing confusion, and simplifying future modifications.

2. Refactor the feedback_response_report Method

The feedback_response_report method begins by fetching all authors (participants) associated with the assignment through the fetch_authors_for_assignment method. It then retrieves the review map IDs for the assignment using ReviewResponseMap.where, followed by fetching the corresponding responses using Response.where. These responses are ordered by their creation time in descending order to ensure that the most recent feedback is prioritized.

Next, the method checks if the assignment uses varying rubrics by round. If this is the case, it initializes a hash (latest_by_map_and_round) to store the latest response for each review map and round combination. The method iterates over the responses, using the combination of map_id and round as the key, and updates the hash with the latest response for each round. Afterward, the responses are grouped by round and sorted, resulting in a hash (sorted_by_round) where each round number maps to an array of response IDs.

In the case where rubrics do not vary by round, the method follows a simpler approach, storing only the latest response for each review map in the latest_by_map hash. It then returns the authors along with the IDs of the most recent responses for each review map.

Finally, the method returns an array: the first element contains the authors, and the second element contains the response IDs grouped by round if rubrics vary by round, or the latest response IDs if they do not. This structure allows for efficient and organized retrieval of feedback responses based on the assignment's rubric configuration.

3. Separate Email Functionality Using the Visitor Pattern

The Visitor pattern is a design pattern that allows new operations to be added to existing object structures without modifying the objects themselves. Using this pattern, the email method can interact with different parts of the system (responses, participants, etc.) without modifying those objects directly.

To separate the email functionality, we created the EmailVisitor class, which is implemented as a service class. It encapsulates the specific action of sending emails to users based on responses, participants, and assignments. By placing this logic in a service class, we ensure that the email functionality remains independent of the models, which helps keep the models focused on their core responsibilities.

The EmailVisitor class implements the Visitor pattern by interacting objects such as responses, response maps, participants, and users. It gathers the necessary data by storing relevant information in instance variables. The visitor then uses this data to construct and send an email, including details like the recipient’s name and the assignment’s information. The visitor pattern facilitates this interaction by allowing the EmailVisitor to operate on these objects without directly modifying them. Each model, such as response, response_map, participant, and user, has an accept method that takes the visitor as an argument and calls the appropriate method on the visitor, passing itself as a parameter. This enables the visitor to perform specific operations on each model without needing to know the internal details of the models. The visitor relies on the accept methods to trigger the correct operation. Additionally, this structure makes it easy to extend functionality, as new operations can be added to the visitor without altering the existing models, a key advantage of the Visitor pattern.

4. Remove Redundant Code and Improve Code Readability and Maintainability

The original code contains unnecessary variables (like @temp_response_map_ids) that tracked the maps in a roundabout way. It also used complicated loops and conditionals to filter responses, leading to logi that is hard to follow. There were also certain duplicated database queries, such as retrieving response maps multiple times.

The refactored code removed the redundant variables and replaced them with a streamlined data structure (latest_by_map_and_round). It removed deep nesting by using hash-based filtering instead of multiple conditionals and used concise ActiveRecord queries to fetch only the necessary records, reducing memory usage and execution time. The refactored code addressed the readability and maintainability issues of the original implementation by breaking down large methods into smaller, focused functions like fetch_authors_for_assignment. Hence, the refactored method is shorter, easier to understand, executes faster with less looping and redundant queries, and has a more straightforward logic for easier future modifications.

Testing

1. Adapt Existing Tests for Refactored Methods

• Any new helper methods will be private, and so by the "Magic Tricks of Testing" guide, should not be tested (both query and command messages sent to self are ignored in the test plan).
• Use mocks to isolate components during testing, especially for external dependencies like Mailer, to ensure that email functionality works as expected without direct integration.

2. Document Code for Clarity

• Write detailed comments explaining the purpose of each method, input and output, and any critical logic that might be complex for future developers to understand.
• Create or update documentation and diagrams to illustrate the newly designed structure, making it easier for new developers to contribute or modify functionality.

Files

The files that were added or modified to our repository are shown below.

Models

feedback_response_map.rb

Many comments were placed throughout the document in order to make code more readable.

Database

migrate/20250324184409_add_round_to_responses

Spec

feedback_response_map_spec.rb

Video

https://drive.google.com/drive/folders/1D47ABE413j1OWY1ad2Gv9mJEQ_YguKH7?usp=sharing

Pull Request

https://github.com/expertiza/reimplementation-back-end/pull/182

Conclusion

By refactoring feedback_response_map.rb, this project enhances Expertiza’s backend maintainability and readability, ensuring a modular, efficient, and more secure implementation.

Team Information

Mentor

• Aniruddha Rajnekar (aarajnek@ncsu.edu)

Members

• Riya Bihani (rbihani@ncsu.edu)

• Nayan Taori (ntaori@ncsu.edu)

• Chandrakant Koneti (ckoneti@ncsu.edu)