CSC/ECE 517 Fall 2024 - E2456. Refactor teams user.rb
Expertiza
Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The National Science Foundation supports the Expertiza project. It is used in select courses at NC State and by professors at several other colleges and universities.
Expertiza is a Ruby on Rails based open source project.
Problem Statement
The TeamsUser class in the Expertiza repository serves as a join model between the Team and Participant classes, establishing a many-to-many relationship. Its primary purpose is to manage team memberships within the context of assignments or courses, facilitating functionalities such as retrieving a user's name, deleting users or teams, and managing participant associations.
The primary issue with the TeamsUser class is that it associates teams directly with users rather than with participants. In the context of the application, participants are users who are specifically associated with an assignment or a course. Since teams are formed within the scope of assignments or courses, handling team memberships through participants is more appropriate. Almost everywhere else, an assignment uses Participant objects rather than User objects. The exception is when it comes to Teams. It would simplify the design to use TeamsParticipants instead of TeamsUsers.
Background
The main role of teams_user class is to handle functionalities that deal with a team associated with an assignment/course and the participants (users associated with a course/assignment) in the team. The functionalities include retrieving a user’s name, deleting a user from the team, deleting the team if no participants are left in the team, adding a member to the team, finding the team ID for a user with a specific assignment, etc. Overall, it encapsulates the logic required to manage participants’ in teams within the context of assignments/courses in Expertiza.
Refactor
The refactoring process involved careful analysis of existing methods, removal of redundancies, and restructuring code to maintain clarity and efficiency. Significant focus was placed on simplifying method names, enhancing documentation, and aligning with object-oriented principles.
The refactor aims to address the inappropriate association of teams directly with users rather than participants, ensuring consistency with the application's architecture. The changes involve:
- Renaming TeamsUser to TeamsParticipant.
- Updating associations and references in related models: Team, User, and Participant.
- Removing empty or unnecessary methods and renaming others for clarity.
- Reducing the code and conditional complexity of the model
- Identifying code smells and refactoring for efficiency.
- Writing tests for all of the methods.
- Ensuring adherence to SOLID and DRY principles.
Files Modified
Changed files in Model:
Changes to app/models/teams_user.rb
| # | Change | Rationale | Commit Link | |
|---|---|---|---|---|
| 1 | Renamed TeamsUser to TeamsParticipant | Aligns with application logic that utilizes Participants rather than Users. | Commit | |
| 2 | Updated associations to reference Participants | Ensures consistency across the application and correctness in related models for foreign key relations. | Commit | |
| 3 | Removed get_team_members from teams_participant model
|
The method was empty without any logic so it was just a placeholder method without any usage across the project. | Commit | |
| 4 | Renamed methods: remove_team_if_participants_empty, remove_team_participant, first_participant_for_team, add_accepted_invitee_to_team, find_team_id for clarity
|
Improves code readability for new programmers. | Commit | |
| 5 | Refactored methods: add_accepted_invitee_to_team, and find_team_id for efficiency and reducing complexity
|
To reduce Cognitive Complexity and making the model more maintainable and efficient | Commit |
Test Cases
Next Steps
During the refactoring from TeamsUser to TeamsParticipant, we initially retained the association between teams and users (with user_id as a foreign key) in TeamsParticipant. This approach was for backward compatibility, ensuring that other classes and tests would function without immediate disruption.
The next phase will involve fully removing this direct association between teams and users. Instead, we will maintain only the teams-participant relationship in the TeamsParticipant table.
This update will require modifying all references to TeamsParticipant across models and controllers, and adjusting logic to work with Participant instead of User. Certain cases do need user-specific fields previously stored within TeamsParticipant. With the user association deprecated, these areas will need updated logic to retrieve the user associated with each participant. This ensures continued functionality and accuracy of the code. Corresponding updates will also be necessary in the spec files to align with the changes.
Team
Mentor
- Jayesh, Kiron
Members
- Agarwal, Arjit
- Manbhekar, Pranav
- Singhania, Chinmay