Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2023 - E2373. Reimplement teams controllers.rb

2023-11-16T00:47:59Z

Njayann: Created page with "===Description of Project=== The project involves a comprehensive restructuring of the teams_controller.rb file and the team.rb model within an application handling team func..."

===Description of Project===

The project involves a comprehensive restructuring of the teams_controller.rb file and the team.rb model within an application handling team functionalities in assignments or courses. The primary focus includes adhering to the Single Responsibility Principle (SRP) by reorganizing methods to have singular, focused tasks and separating team-copying functionalities. Additionally, the effort involves refining function names for better clarity and readability and enhancing comments across the codebase to improve understanding. This overhaul aims to optimize the codebase for maintainability and readability while preserving or enhancing the functionality of team-related operations in the application.

===Problem Statement===

The problem statement revolves around the inefficiencies and complexities present in the teams_controller.rb file and the team.rb model within an application managing team functionalities for assignments or courses. These inefficiencies primarily stem from violations of the Single Responsibility Principle (SRP), evident in functions that encompass multiple tasks and unclearly named functions that hinder code readability. Additionally, inadequate comments further exacerbate the code's readability issues. The challenge is to refactor these components, focusing on SRP compliance by restructuring methods, improving naming conventions for better understanding, and enhancing comments to facilitate code comprehension. The goal is to optimize the codebase for maintainability and readability while preserving or enhancing the functionality of team-related operations in the application.

===Objectives===

1. Single Responsibility Principle (SRP) Adherence

*Refactor methods in teams_controller.rb and team.rb model to ensure each function has a singular, focused responsibility.
*Separate team-related functionalities like copying between assignments/courses for better code organization.

2. Improved Naming Conventions

*Rename ambiguous or confusingly named functions in both teams_controller.rb and team.rb for enhanced code readability and understanding.

3. Enhanced Comments and Documentation

*Improve and add comments throughout the codebase to provide clearer explanations of complex functionalities and enhance overall code comprehension.
*Document significant changes made during refactoring to aid future maintenance and development.

4. Code Refactoring and Consolidation

*Identify and eliminate code repetitions across functions to streamline the codebase, enhancing maintainability and reducing redundancy.

5. Testing and Validation

*Create or update unit tests to ensure the correctness and functionality of refactored methods in both the teams_controller.rb and team.rb model.
*Conduct integration testing to verify the overall functionality of team-related operations post-refactoring.

The objectives aim to optimize the codebase by adhering to SRP principles, improving code readability through better naming conventions and comments, consolidating code where possible, and ensuring thorough testing for functionality validation.

===Development Strategy===

Our development strategy centers around Test-Driven Development (TDD) principles applied to refactoring the teams_controller.rb and team.rb model. Starting with the creation of failing test cases, we iteratively refactor code to address identified inefficiencies while ensuring successful test outcomes.

Additionally, we emphasize the adoption of a "Slim controller, Fat model" paradigm inspired by Rails conventions. Our goal is to migrate complex functionalities from the controller to the model, fostering a more organized and maintainable codebase. This approach not only enhances code clarity within the controller but also promotes reusability and scalability across the application.

===Project Design and Implementation===

Taking into account the current functionalities within the teams_controller.rb and team.rb model, our approach involves embracing the Strategy Pattern within the controller, capitalizing on 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 ====
In this project, we aim to add functions for the following:

1. Refactoring for SRP:
*Reorganizing code in teams_controller.rb and team.rb to adhere to the Single Responsibility Principle.

2. Naming and Comment Improvements:
*Enhancing function and method names for clarity.
*Adding and refining comments for better code comprehension.

3. Code Optimization:
*Identifying and removing redundant code segments to streamline the codebase.

4. Testing and Validation:
*Creating or updating tests to ensure the accuracy of refactored methods.
*Conducting integration tests to verify overall functionality post-refactoring.

===Testing Plan===

We plan to employ RSpec for comprehensive testing of the teams_controller.rb and team.rb model. Leveraging FactoryBot, we'll construct the necessary test fixtures and models for thorough testing. Our approach involves utilizing the existing test skeleton provided while enhancing test coverage and minimizing code smells. Considering the current functionalities, our defined tests aim to validate the restructured code in the teams_controller.rb and team.rb model, verifying improved functionality and reduced code smells.

===Relevant Links===
Github Repository: https://github.com/Naveen-Jayanna/expertiza

===Team Members===
*Samarth Purushothaman

*Naveen Jayanna

*Arpit Choudhary

===Mentor===
Aditi Vakeel

CSC/ECE 517 Fall 2023

2023-11-16T00:17:19Z

Njayann:

* [[CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2023 - E2351. Finish mentor management for assignments without topics]]
* [[CSC/ECE 517 Fall 2023 - E2352. Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Fall 2023 - E2353. Further refactoring and improvement of review mapping helper]]
* [[CSC/ECE 517 Fall 2023 - E2355. Improving Search Facility In Expertiza]]
* [[CSC/ECE 517 Fall 2023 - E2356. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2023 - E2357. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2023 - E2358. Refactor student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2023 - E2359. Refactor user_controller.rb, user.rb, and its child classes]]
* [[CSC/ECE 517 Fall 2023 - E2360. View for Results of Bidding]]
* [[CSC/ECE 517 Fall 2023 - E2361. Create a page to create and update a Questionnaire in ReactJS]]
* [[CSC/ECE 517 Fall 2023 - E2362. Create a page to edit an Assignment's due date in ReactJS]]
* [[CSC/ECE 517 Fall 2023 - E2363. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Fall 2023 - E2364. Create a UI for Course's & Assignment's "Add Participants" page]]
* [[CSC/ECE 517 Fall 2023 - E2365. Create a user interface for Questionnaire in ReactJS]]
* [[CSC/ECE 517 Fall 2023 - E2363. Create a UI for Assignment Edit page "Etc" tab in ReactJS(Phase 2)]]
* [[CSC/ECE 517 Fall 2023 - E2366. Reimplement assignment model and assignment controller]]
* [[CSC/ECE 517 Fall 2023 - E2367. Reimplement participants_controller.rb, participants.rb and its child classes]]
* [[CSC/ECE 517 Fall 2023 - E2368. Reimplement of due_date.rb]]
* [[CSC/ECE 517 Fall 2023 - E2369. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Fall 2023 - E2370. Reimplement join team requests controller]]
* [[CSC/ECE 517 Fall 2023 - E2371. Reimplement quiz_questionnaires_controller]]
* [[CSC/ECE 517 Fall 2023 - E2373. Reimplementation of teams controller]]
* [[CSC/ECE 517 Fall 2023 - E2373. Reimplement teams_controllers.rb]]
* [[CSC/ECE 517 Fall 2023 - E2374. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Fall 2023 - E2375. Reimplement Waitlists]]
* [[CSC/ECE 517 Fall 2023 - E2376. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Fall 2023 - E2379. Reimplement authorization_helper.rb]]
* [[CSC/ECE 517 Fall 2023 - E2380. Reimplement frontend for Courses]]
* [[CSC/ECE 517 Fall 2023 - E2382. Optimizing the LatePoliciesController]]
* [[CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail]]
* [[CSC/ECE 517 Fall 2023 - E2384. Reimplement user_controller.rb, user.rb and its child classes]]
* [[CSC/ECE 517 Fall 2023 - E2385. Create a Courses User interface in ReactJS]]
* [[CSC/ECE 517 Fall 2023 - E2386. Reimplement teams_users backend]]
* [[CSC/ECE 517 Fall 2023 - E2377. Reimplement impersonating users (functionality within impersonate_controller.rb)]]
* [[CSC/ECE 517 Fall 2023 - NTX-1 Adding Snapshot Controller/API and CRDs]]
* [[CSC/ECE 517 Fall 2023 - NTX-2 Observability and Debuggability]]
* [[CSC/ECE 517 Fall 2023 - NTX-3 Usability and Security]]
* [[CSC/ECE 517 Fall 2023 - NTX-4 Extend NDB Operator capabilities to support Postgres HA]]
* [[CSC/ECE 517 Fall 2023 - G2350. Add GitLab support for using GraphQL to query user metrics 1]]
* [[CSC/ECE 517 Fall 2023 - G2352. Add GitLab support for using GraphQL to query repository information]]

CSC/ECE 517 Fall 2023 - E2368. Reimplement of due date.rb

2023-11-07T01:25:02Z

Njayann: Updated the test plan section

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Removed methods used exclusively in test files.
* Created a new file, due_date_helper.rb, to handle specific functionalities.
* Moved pertinent methods from the model class to the new helper class.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Renamed methods to accurately describe their responsibilities.
* Addressed identified code smells and issues using Code Climate analysis.

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in three key points:

=== Deadline and Time Handling ===
The class manages due dates for various elements within an assignment. It includes functionalities to:
* Determine the current due date based on time comparisons.
* Check for teammate review allowance based on due dates.
* Set flags and validate due date formats.

=== Assignment and Topic-Based Due Date Retrieval ===
The class retrieves the next due date for assignments or topics. It includes logic to:
* Handle staggered deadlines for topics and fallback procedures for unavailable topic-specific due dates.
* Retrieve assignment-specific due dates considering the current time.

=== Functionality for Assignment Duplication ===
The class offers methods to handle due date duplication between assignments. It includes functionalities to:
* Copy due dates from one assignment to another.
* Set due dates for assignments based on various parameters.
* Calculate assignment-specific rounds for responses like author feedback, quizzes, and reviews based on deadlines.

This `DueDate` class serves as a central component within the Expertiza project for managing and handling due dates, validation, and retrieval concerning assignment and deadline management.
== Improvements in the New Implementation of DueDate Class ==

The changes made in the new implementation of the `DueDate` class addressed several issues, along with their corresponding solutions:

=== Removed methods used only in the test files ===
* '''Problem''': The code contained methods tailored exclusively for testing, leading to unnecessary clutter and potential confusion within the primary codebase.
* '''Solution''': Removal of test-specific methods streamlined the code, enhancing focus and clarity, ensuring that the main code is more comprehensible for developers working on functional components.

The method `set_duedate` was originally housed in the `due_date.rb` file and was later relocated to the `due_date_spec.rb` file within the Expertiza project. This method is responsible for setting a due date.

The relocated `set_duedate` method performs the following tasks:
<pre>
def self.set_duedate(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.deadline_type_id = deadline
submit_duedate.parent_id = assign_id
submit_duedate.round = max_round
submit_duedate.save
end
</pre>

=== Created a new due_date_helper.rb file ===
* '''Problem''': The primary model class had an abundance of methods, including helper functions, affecting readability and maintainability.
* '''Solution''': The establishment of a dedicated file for due date helper methods segregated the code, enabling a clear distinction between model-specific functions and those supporting due date functionalities, leading to improved modularity and organization.

=== Moved relevant methods from the model class to the helper class ===
* '''Problem''': The model class contained methods better suited for helper functions, violating the Single Responsibility Principle and causing complexity.
* '''Solution''': Relocating pertinent methods to the helper class aligned the code with the Single Responsibility Principle, enhancing maintainability and organization by ensuring distinct purposes for each class.

Below are the contents of the newly implemented file app/helpers/due_date_helper.rb

<pre>
# frozen_string_literal: true

# app/helpers/due_date_helper.rb

# This module contains helper methods related to due dates.
module DueDateHelper
def self.deadline_sort(due_dates)
# Override the comparator operator to sort due dates by due_at
due_dates.sort { |m1, m2| m1.due_at.to_i <=> m2.due_at.to_i }
end

...
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Before refactoring

<pre>
def self.done_in_assignment_round(assignment_id, response)
# for author feedback, quiz, teammate review and metareview, Expertiza only support one round, so the round # should be 1
return 0 if ResponseMap.find(response.map_id).type != 'ReviewResponseMap'

due_dates = DueDate.where(parent_id: assignment_id)
# sorted so that the earliest deadline is at the first
sorted_deadlines = deadline_sort(due_dates)
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
round = 1
sorted_deadlines.each do |due_date|
break if response.created_at < due_date.due_at

round += 1 if due_date.deadline_type_id == 2
end
round
end
</pre>

After refactoring

<pre>
def self.calculate_assignment_round(assignment_id, response)
return 0 unless ResponseMap.find(response.map_id).type == 'ReviewResponseMap'

due_dates = DueDate.where(parent_id: assignment_id)
sorted_deadlines = deadline_sort(due_dates)
determine_assignment_round(response, sorted_deadlines)
end

def self.determine_assignment_round(response, sorted_due_dates)
round = 1
sorted_due_dates.each do |due_date|
break if response.created_at < due_date.due_at

round += 1 if due_date.deadline_type_id == 2
end
round
end
</pre>

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Before Renaming

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.get_next_due_date(assignment_id, topic_id = nil)
</pre>

<pre>
def self.calculate_assignment_round(assignment_id, response)
..
def set_due_date(duedate, deadline, assign_id, max_round)
..
def self.find_next_topic_due_date(assignment_id, topic_id)
</pre>

=== Fixed code smells using Code Climate ===
* '''Problem''': Code Climate identified issues like inefficiencies, redundancies, or style violations, potentially impacting code quality and maintainability.
* '''Solution''': Addressing Code Climate's feedback resolved potential issues, leading to an optimized, robust, and maintainable codebase aligning with higher standards.

Before refactoring, the same block of code given below was present in due_date_spec.rb and due_date_helper_spec.rb

<pre>
before(:each) do
@deadline_type = build(:deadline_type)
@deadline_right = build(:deadline_right)
@assignment_due_date = build(:assignment_due_date, deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id, review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id, due_at: '2015-12-30 23:30:12')

@due_dates = []
10.times.each do |n|
date = if n == 1 || n == 9
nil
else
Time.zone.now - 60 * n
end
@due_dates << build(:assignment_due_date, due_at: date)
end
end
</pre>

After refactoring, we created a new file spec/support/shared_contexts.rb to house the common block of code.

<pre>
RSpec.shared_context 'with_deadline_setup' do
before(:each) do
@deadline_type = build(:deadline_type)
@deadline_right = build(:deadline_right)
@assignment_due_date = build(
:assignment_due_date,
deadline_type: @deadline_type,
submission_allowed_id: @deadline_right.id,
review_allowed_id: @deadline_right.id,
review_of_review_allowed_id: @deadline_right.id,
due_at: '2015-12-30 23:30:12'
)

@due_dates = []
10.times.each do |n|
date = if n == 1 || n == 9
nil
else
Time.zone.now - 60 * n
end
@due_dates << build(:assignment_due_date, due_at: date)
end
end
end
</pre>

By recognizing these problems and applying their respective solutions, the new implementation of the `DueDate` class aims to enhance code quality, readability, and maintainability within the Expertiza project.

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

=== Calculate Assignment Round ===
* Scenario: Confirm that the method returns the correct round number based on the response map presence.
* Edge Case: Test with an invalid assignment id to ensure robustness against unexpected inputs.

=== Copy Due Dates to New Assignment ===
* Scenario: Check that due dates are accurately duplicated from one assignment to another.
* Edge Case: Try copying from an assignment with no due dates and ensure the system reacts correctly.

=== Create New DueDate Record ===
* Scenario: Ensure that a new due date record is created with specified attributes.
* Edge Case: Try creating a due date with invalid parameters to test the validation process.

=== Get Next Due Date ===
* Scenario: Validate that the system can retrieve the next due date for an assignment when available.
* Edge Case: Check retrieval when the next due date is in the past or when there's no subsequent due date.

=== Default Permission Checks ===
* Scenario: Verify that the system returns default permissions correctly for various deadline types and actions.
* Edge Case: Examine the behavior when checking permissions for non-existent deadline types.

=== Metareview and Review Permissions ===
* Scenario: Test that default permissions for metareview and review phases meet the system's expectations.

=== Deadline Right Permission Constants ===
* Scenario: Confirm that the DeadlineRight module includes accurate default permission constants.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/samarth-p/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin