CSC/ECE 517 Spring 2024 - E2406 Refactor review mapping helper.rb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
(Created page with "This wiki page describes changes made under the E2405 OODD assignment for Spring 2024, CSC/ECE 517. __TOC__ == Expertiza Background== Expertiza is an open-source online application developed using Ruby on Rails framework. It is maintained by the staff and students at NC State University. This application provides instructors with comprehensive control over managing tasks and assignments in their courses. Expertiza offers a wide range of powerful features, including peer...")
 
No edit summary
 
(57 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This wiki page describes changes made under the E2405 OODD assignment for Spring 2024, CSC/ECE 517.
== Team ==
__TOC__
=== Mentor ===
* Ananya Mantravadi  (amantra)
 
=== Team Members ===
* Ravi Ghevariya (rghevar)
* Manan Patel (mrpatel8)
* Kanishk Harde (knharde)
 
=== Relevant Links ===
* '''Link to Expertiza Repository:''' https://github.com/expertiza/expertiza <br>
 
* '''Link to Forked Repository: ''' https://github.com/kanishkharde/expertiza <br>
 
* ''' Link to Pull Request: '''https://github.com/expertiza/expertiza/pull/2802<br>
 
== Expertiza Background==
== Expertiza Background==
Expertiza is an open-source online application developed using Ruby on Rails framework. It is maintained by the staff and students at NC State University. This application provides instructors with comprehensive control over managing tasks and assignments in their courses. Expertiza offers a wide range of powerful features, including peer review management, group formation, and subject addition capabilities. It is a versatile platform that can handle various types of assignments. For more detailed information about the extensive features offered by Expertiza, users can refer to the Expertiza wiki.
Expertiza is a Ruby on Rails framework-based open-source web application. It is kept up by NC State University employees and students. With the help of this program, instructors can fully manage the assignments and responsibilities assigned in their classes. Expertiza provides many strong features, such as subject addition, group creation, and peer review administration. It is a flexible platform that can manage many kinds of tasks. Users can consult the Expertiza wiki to get more in-depth details about the many capabilities that Expertiza offers.


== About Helper ==
== About Helper ==
The '''review_mapping_helper''' module in Ruby on Rails provides a set of helper methods to facilitate the peer review process in an assignment. It includes functionality for generating review reports, managing submission statuses, calculating review scores, and visualizing review metrics, but requires refactoring to improve code maintainability and readability.
The Ruby on Rails '''review_mapping_helper''' module offers a number of helper methods to make the peer review process easier in assignments. It has the capacity to calculate review scores, manage submission statuses, generate review reports, and visualize review metrics; however, it needs to be refactored in order to make the code more readable and maintainable.
 
== Functionality of review_mapping_controller ==
The review_mapping_helper.rb file is a Ruby module that contains various helper methods related to the review mapping process in a peer review system. Here's a brief overview of the main functionalities provided by this module:
 
1. Generating review reports with data such as reviewer IDs, reviewed object IDs, and response types. <br/>
2. Determining team colors based on review status and assignment submission status. <br/>
3. Checking submission states within each round and assigning team colors accordingly. <br/>
4. Retrieving and displaying submitted hyperlinks and files for review.<br/>
5. Calculating awarded review scores and determining minimum, maximum, and average grade values.<br/>
6. Sorting reviewers based on the average volume of reviews in each round.<br/>
7. Generating and displaying charts for review volume metrics and tagging time intervals.<br/>
8. Retrieving and setting up review and feedback responses for feedback reports.<br/>
9. Determining CSS styles for the calibration report based on the difference between student and instructor answers.<br/>
10. Defining and calculating review strategies for students and teams, including reviews per team, reviews needed, and reviews per student.<br/>


== Problem Statement ==
== Problem Statement ==
Because of its length, complexity, and lack of comments, the review_mapping_helper is challenging for developers to understand and utilize effectively. The controller should go through a thorough restructuring process to remedy this, with the goal of dividing complex procedures into smaller, easier-to-manage parts. To do this, complex logic must be broken down into modular parts, each of which is in charge of a particular task or subtask that contributes to the overall functioning. In order to improve maintainability and lower the chance of errors, the refactoring effort should also focus on cases of code duplication, combining redundant code segments into reusable functions or utility methods. Developers can better grasp the inner workings of the controller codebase and make maintenance, debugging, and future additions easier by methodically rearranging the codebase and increasing its documentation.
The existing codebase derived from E2301 suffers from lack of clarity, violating the Expert pattern, and inefficient methods, hindering code understandability and maintainability. Key issues include convoluted data handling in views, unclear color-coding methods, and inefficient sorting functions. Additionally, redundant methods and unclear feedback_response_maps further obscure the code's purpose.


== Tasks ==
== Tasks ==
- Refactor the file to reduce the overall lines of code to be within the allowed limit of 250 lines.<br/>
1. Refactor get_data_for_review_report to use partials for clearer code in views/reports.<br/>
- Refactor the <code>`display_volume_metric_chart`</code> method to reduce its lines of code to be within the allowed limit of 25 lines.<br/>
2. Refactor color-related methods for clarity and consistency, using American spelling.<br/>
- Refactor the <code>`display_tagging_interval_chart`</code> method to reduce its lines of code to be within the allowed limit of 25 lines.<br/>
3. Rename methods starting with "get" to adhere to Ruby conventions.<br/>
- Refactor the <code>`check_submission_state`</code> method to reduce its Cognitive Complexity to be within the allowed limit of 5 and reduce the number of arguments to be within the allowed limit of 4.<br/>
4. Update get_awarded_review_score to utilize standardized score-calculation code.<br/>
- Refactor the <code>`sort_reviewer_by_review_volume_desc`</code> method to reduce its Cognitive Complexity to be within the allowed limit of 5.<br/>
5. Generalize sort_reviewer_by_review_volume_desc for sorting by various metrics.<br/>
- Refactor the <code>`review_metrics`</code> method to reduce its Cognitive Complexity to be within the allowed limit of 5.<br/>
6. Extracting chart-generating methods into their own module or evaluating the necessity of list_review_submissions<br/>
- Refactor the <code>`get_team_color`</code> method to reduce its Cognitive Complexity to be within the allowed limit of 5.<br/>
7. Review and clarify the purpose of feedback_response_maps methods.<br/>
- Reduce the number of arguments for the <code>`check_submission_state`</code> method from 5 to 4. <br/>
8. Add comments or refactor small classes for clarity and documentation.<br/>


=== Phase 1 ===
=== Phase 1 ===
For Phase 1 of the project we have focused working on the below mentioned issues: <br/>
We have concentrated our efforts on addressing the following difficulties throughout the project's first phase: <br/>
- Refactor the <code>`display_volume_metric_chart`</code> method.<br/>
1. Refactor get_data_for_review_report to use partials for clearer code in views/reports.<br/>
- Refactor the <code>`review_metrics`</code> method.<br/>
2. Refactor color-related methods for clarity and consistency, using American spelling.<br/>
- Commented the code. <br/>
3. Rename methods starting with "get" to adhere to Ruby conventions.<br/>
- Fixed Code climate issues. <br/>
8. Add comments or refactor small classes for clarity and documentation.<br/>


=== Phase 2 ===
=== Phase 2 ===
For Phase 2 of the project we plan working on the below mentioned issues: <br/>
We have planned our efforts on addressing the following difficulties throughout the project's second phase: <br/>
- Refactor the <code>`display_tagging_interval_chart`</code> method.<br/>
4. Update get_awarded_review_score to utilize standardized score-calculation code.<br/>
- Refactor the <code>`check_submission_state`</code> method.<br/>
5. Generalize sort_reviewer_by_review_volume_desc for sorting by various metrics.<br/>
- Refactor the <code>`sort_reviewer_by_review_volume_desc`</code> method.<br/>
6. Extracting chart-generating methods into their own module or evaluating the necessity of list_review_submissions<br/>
- Refactor the <code>`get_team_color`</code> method.<br/>
7. Review and clarify the purpose of feedback_response_maps methods.<br/>
- Reduce the number of arguments for the <code>`check_submission_state`</code> method. <br/>
 
- Increase the test coverage. <br/>
- Increase code readability. <br/>


== Implementation ==
== Implementation ==
Line 55: Line 53:
=== Phase 1 ===
=== Phase 1 ===


==== Refactor the <code>`display_volume_metric_chart`</code> method ====
==== Refactor the <code>`get_data_for_review_report`</code> method ====
The <code>`display_volume_metric_chart`</code> method has been modified to address the issue of reducing its length to 25 lines. The changes made are as follows:
[[File:t1.jpg|750px]]


- The method now focuses solely on preparing the data and options for the chart and rendering the chart using the <code>`bar_chart`</code> method. <br/>
==== Refactor the <code>`color-related`</code> methods ====
- The logic for preparing the chart data has been extracted into a separate method called <code>`prepare_chart_data`</code>. This method takes the labels, reviewer_data, and all_reviewers_data as parameters and returns a hash containing the formatted data required for the chart.<br/>
[[File:t2.jpg|750px]]
- Similarly, the logic for preparing the chart options has been moved to a separate method called <code>`prepare_chart_options`</code>. This method returns a hash containing the configuration options for the chart, such as legend settings, width, height, and axis properties.<br/>
- By extracting the data preparation and options configuration into separate methods, the <code>`display_volume_metric_chart`</code> method becomes more concise and focused on its main responsibility of displaying the chart.<br/>
- The <code>`prepare_chart_data`</code> method constructs the hash structure required by the charting library, including the labels and datasets. It sets the label, background color, border width, data, and yAxisID for each dataset.<br/>
- The <code>`prepare_chart_options`</code> method defines the options for the chart, such as the legend position and style, chart dimensions, and axis configurations. It specifies the stacking, thickness, and other properties for the y-axes and x-axis.<br/>


==== Refactor the <code>`review_metrics`</code> method ====
==== Rename methods starting with <code>`get`</code> to adhere to Ruby conventions methods ====
Several changes have been made to reduce the cyclomatic complexity of the review_metrics method from 6 to 5. Let's go through the changes:
[[File:t3.jpg|750px]]


- The array of metrics %i[max min avg] is assigned to a variable metrics at the beginning of the method for better readability and reusability.<br/>
== Design Pattern ==
- The code for initializing the metrics with the default value '-----' has been extracted into a separate private method called <code>`initialize_metrics`</code>. This method iterates over the metrics array and sets the corresponding instance variables using string interpolation.<br/>
The Refactoring pattern is essential to enhance code readability, maintainability, and adherence to best practices. By systematically restructuring code components, eliminating redundancies, and applying standard conventions, the Refactoring pattern ensures improved code quality and easier future modifications.
- The condition for checking if the team data is available has been moved to a separate private method called <code>`team_data_available?`</code>. This method takes team_id, round, and metrics as parameters and returns a boolean value indicating whether the data is available for all metrics in the given round for the specified team.<br/>
- The code for updating the metrics based on the available data has been moved to a separate private method called <code>`update_metrics`</code>. This method iterates over the metrics array and updates the corresponding instance variables with the metric values fetched from the @avg_and_ranges hash.<br/>
- The logic for fetching the metric value has been extracted into a separate private method called <code>`fetch_metric_value`</code>. This method takes team_id, round, and metric as parameters and returns the formatted metric value. If the value is nil, it returns '-----'; otherwise, it rounds the value to 0 decimal places and appends a '%' symbol.<br/>
- The <code>`review_metrics`</code> method now has a more linear flow. It initializes the metrics using <code>`initialize_metrics`</code>, checks if the team data is available using <code>`team_data_available?`</code>, and updates the metrics using <code>`update_metrics`</code> if the data is available. If the data is not available, the method returns early without updating the metrics.<br/>


== Test Plan ==
==Plan of work==
We intend to expand Project 4's test coverage by introducing more tests.


Throughout our Test-Driven Development (TDD) efforts, our group would systematically use the painstakingly constructed test skeletons of Vyshnavi Adusumelli and Mustafa Olmez. These painstakingly crafted skeletons will function as priceless blueprints, outlining the fundamental tests required for our unit. We thoroughly test our controller module by including these painstakingly created test skeletons into our workflow. With this approach, we would be able to investigate the workings of our controller in great detail, making sure that its actions are carefully reviewed and verified. Adding these test skeletons will improve our codebase's general quality and reliability while also providing a solid foundation for our unit tests.
We began our work by examining the <code>review_mapping_helper.rb</code> file to understand its connection to the rest of the codebase. We then had detailed discussions with our mentor about the project's flow and structure. We organized our project requirements by difficulty levels, assigned tasks among the team, and began refactoring existing methods and creating new files as needed. We made sure to preserve the integrity of existing test cases while adding new ones where needed.


'''Test Plan'''
=='''Project 4 - DESIGN DOC'''==
We have been assigned below-cited changes to do after project 3


1. Test <code>`create_report_table_header`</code> method:<br/>
===4. Refactoring get_awarded_review_score Method:===
  - Test case: when headers are provided<br/>
* Standardize the score-calculation logic to ensure consistency and readability.<br/>
  - Test case: when no headers are provided<br/>
* Break down complex calculations into smaller, more understandable components.<br/>
* Improve method documentation and clarity to enhance understanding.<br/>


2. Test <code>`review_report_data`</code> method:<br/>
===5. Generalizing sort_reviewer_by_review_volume_desc:===
  - Test case: when valid parameters are provided<br/>
* Modify the method to accept flexible sorting metrics, enabling customization based on various criteria.<br/>
    - Test scenario 1: when there are response maps for the given reviewed object, reviewer, and type<br/>
* Update method documentation to reflect the changes and provide usage guidelines.<br/>
    - Test scenario 2: when there are no response maps for the given reviewed object, reviewer, and type<br/>
  - Test case: when invalid parameters are provided<br/>
    - Test scenario 1: when the reviewed object does not exist<br/>
    - Test scenario 2: when the reviewer does not exist<br/>
    - Test scenario 3: when the type is invalid<br/>


3. Test <code>`calculate_response_counts`</code> method:<br/>
===6. Code Organization Enhancements:===
  - Test case: when given an empty response_maps array<br/>
* Extract chart-generating methods into separate modules or classes for better organization and reusability.<br/>
  - Test case: when given response_maps with no responses for any round<br/>
* Evaluate the necessity of list_review_submissions method based on insights from the Expertiza wiki and refactor accordingly.<br/>
  - Test case: when given response_maps with responses for all rounds<br/>
  - Test case: when given response_maps with responses for some rounds<br/>


4. Test <code>`get_team_color`</code> method:<br/>
===7. Documentation and Clarity Improvements:===
  - Test case: when a response exists for the response map<br/>
* Review methods related to feedback_response_maps and add comments or refactor small classes to enhance clarity and documentation.<br/>
  - Test case: when no response exists for the response map<br/>
* Ensure consistent naming conventions and adherence to coding standards throughout the codebase.<br/><br/>
  - Test case: calls obtain_team_color method with the correct arguments<br/>


5. Test <code>`obtain_team_color`</code> method:<br/>
'''This section contains changes and contributions to Project 4'''
  - Test case: when there is only one round of review<br/>
----
  - Test case: when there are multiple rounds of review<br/>
  - Test case: when there are no rounds of review<br/>


6. Test <code>`check_submission_state`</code> method:<br/>
'''Issue #4:''' Method <code>get_awarded_review_score</code> needs to be refactored
  - Test case: when the submission is within the round<br/>
*'''Methods involved:''' <code>get_awarded_review_score</code><br>
  - Test case: when the submission is not within the round<br/>
*'''Solution:'''After addressing Issue 2, the method was renamed to <code>determine_awarded_review_score</code> to align with Ruby conventions. Additionally, redundant instance variable settings were moved inside the loop to streamline the code. The explicit nil or -1.0 checks were eliminated and integrated into the <code>instance_variable_set</code> line. <br>
    - Test case: when the link is not provided or does not start with 'https://wiki'<br/>
*'''Changes'''
    - Test case: when the link is provided and starts with 'https://wiki'<br/>
[[File:Issue4.jpg]]
      - Test case: when the link has been updated since the last round<br/>
<br><br>
      - Test case: when the link has not been updated since the last round<br/>


7. Test <code>`response_for_each_round`?</code> method:<br/>
----
  - Test case: when all rounds have a response<br/>
  - Test case: when not all rounds have a response<br/>
  - Test case: when no rounds have a response<br/>


8. Test <code>`submitted_within_round`?</code> method:<br/>
'''Issue #5:''' The method <code>sort_reviewer_by_review_volume_desc</code> should be generalized so that it can sort by any metric, not just review volume. Other metrics might include number of suggestions, or number of suggestions + number of problems detected. This method should not be counting the number of review rounds! Since other places in the code will need to know the number of review rounds, it should be calculated somewhere else in the system.<br/>
  - Test case: when the round is greater than 1<br/>
*'''Methods involved:''' <code>sort_reviewer_by_review_volume_desc</code><br/>
    - Test case: returns true if a submission exists within the previous round's deadline and the current round's deadline<br/>
*'''Problem:''' The current function, sort_reviewer_by_review_volume_desc, arranges reviewers in descending order based solely on review volume. This limited approach means it can't be applied to sorting by other metrics.<br/>
    - Test case: returns false if no submission exists within the previous round's deadline and the current round's deadline<br/>
*'''Solution:'''The idea is to create a more versatile approach by changing the name of <code>sort_reviewer_by_review_volume_desc</code> to <code>sort_reviewer_desc</code> and allowing a metric argument for sorting reviewers, as demonstrated below. This modification was also applied to the <code>review_report</code> section where it was originally used.<br>
  - Test case: when the round is 1<br/>
*'''Changes'''
    - Test case: returns true if a submission exists within the assignment creation date and the current round's deadline<br/>
[[File:5_1.jpg]]
    - Test case: returns false if no submission exists within the assignment creation date and the current round's deadline<br/>
<br><br>
[[File:Issue_Metrics5.jpg]]
<br><br>
----


9. Test <code>`submitted_hyperlink`</code> method:<br/>
'''Issue #6:''' make a separate file for for chart related elements in <code>review_mapping_helper.rb</code><br>
  - Test case: when there is a submission due date and a submission record<br/>
*'''Methods involved:''' <code>display_volume_metric_chart()</code>, <code>display_tagging_interval_chart()</code><br>
    - Test scenario 1: returns the content of the last submitted hyperlink within the assignment creation and due dates<br/>
*'''Previous Code:''' The methods mentioned used to be included in the review_mapping_helper.rb file, but they should have been in their own helper file.<br>
    - Test scenario 2: returns nil if there is no submission due date or submission record for the reviewee team<br/>
*'''Problem:''' These techniques carry out comparable functions in creating graphs and can be implemented as either distinct modules or mixins. Additionally, each method contains more than 30 lines, making them excessively lengthy.<br>
    - Test scenario 3: returns nil if there is a submission due date but no submission record for the reviewee team<br/>
*'''Solution:''' Created new module named 'Charts' withinthe same file. This way the chart helper methods are separated from review_mapping_helper where they are out of place and difficult for any developer to find. <br>
    - Test scenario 4: returns nil if there is a submission record but no submission due date for the reviewee team<br/>
*'''Changes'''
[[File:Issue6.jpg]]<br><br>
[[File:Issue6.2.jpg]]
<br><br>
----


10. Test <code>`last_modified_date_for_link`</code> method:<br/>
'''Issue #7:''' Several methods for feedback_response_maps, check docs to manage this confusion<br/>
    - Test case: when given a valid link<br/>
*'''Methods involved:''' <code> feedback_response_for_author()</code><br/>
    - Test case: when given an invalid link<br/>
*'''Previous Code:''' previous code had an ambiguous variable name<br/>
*'''Problem:''' The purpose of the variable was unclear.<br/>
*'''Solution:''' Rename the variable to enhance its clarity and provide comments to explain its purpose clearly.<br/>
*'''Changes'''
[[File:Issue7.jpg]]
<br><br>
----


11. Test <code>`link_updated_since_last`?</code> method:<br/>
==Test Plan==
    - Test case: when the link was updated before the submission due date for the current round and after the submission due date for the previous round<br/>
This project involves refactoring, meaning that the original functionality should remain unchanged. Tasks included adding comments to existing code, altering variable names, and similar adjustments that didn't affect the test cases. When method names were modified or moved to different files, corresponding changes were made in the relevant RSpec files. All test cases passed successfully, indicating that the refactoring didn't break the existing functionality.
    - Test case: when the link was updated after the submission due date for the current round<br/>
<br>
    - Test case: when the link was updated before the submission due date for the previous round<br/>


12. Test <code>`reviewed_link_name_for_team`</code> method:<br/>
<br>The image below shows the test cases are passing as well as most of the code climate issues were resolved.<br><br>
    - Test case: when max_team_size is 1<br/>
[[File:Wiki5.jpg]]
    - Test case: when max_team_size is not 1<br/>
 
13. Test <code>`warded_review_score`</code> method:<br/>
    - Test case: when reviewer_id and team_id are valid<br/>
      - Test scenario 1: sets the correct awarded review score for each round<br/>
      - Test scenario 2: sets the correct awarded review score for each round<br/>
      - Test scenario 3: sets the correct awarded review score for each round<br/>
      - Test scenario 4: sets the correct awarded review score for each round<br/>
    - Test case: when team_id is nil or -1.0<br/>
      - Test scenario 1: does not update any instance variables<br/>
      - Test scenario 2: does not update any instance variables<br/>
 
14. Test <code>`review_metrics`</code> method:<br/>
    - Test case: when given a round and team_id<br/>
      - Test case: sets max, min, and avg to '-----' as default values<br/>
      - Test case: sets max, min, and avg to the corresponding values from avg_and_ranges if present<br/>
 
15. Test <code>`sort_reviewers_by_average_volume`</code> method:<br/>
    - Test case: sorts the reviewers by the average volume of reviews in each round in descending order<br/>
 
16. Test <code>`sort_reviewer_by_review_volume_desc`</code> method:<br/>
    - Test case: when there are reviewers and review volumes available<br/>
      - Test case: calculates the volume of review comments for each reviewer<br/>
      - Test case: sets the overall average volume of review comments for each reviewer<br/>
      - Test case: sets the average volume of review comments per round for each reviewer<br/>
      - Test case: sorts the reviewers by their review volume in descending order<br/>
      - Test case: gets the number of review rounds for the assignment<br/>
      - Test case: sets the average volume of review comments per round for all reviewers<br/>
 
17. Test <code>`initialize_chart_elements`</code> method:<br/>
    - Test case: when reviewer has data for all rounds<br/>
    - Test case: when reviewer has no data for any round<br/>
    - Test case: when reviewer has data for some rounds<br/>
 
18. Test <code>`display_volume_metric_chart`</code> method:<br/>
    - Test case: when given a reviewer<br/>
      - Test case: initializes chart elements<br/>
      - Test case: creates the data for the volume metric chart<br/>
      - Test case: creates the options for the volume metric chart<br/>
      - Test case: displays the volume metric chart<br/>
 
19. Test <code>`display_tagging_interval_chart`</code> method:<br/>
    - Test case: when intervals are all below the threshold<br/>
    - Test case: when intervals contain some values above the threshold<br/>
      - Test case: filters out the values above the threshold<br/>
      - Test case: calculates the mean time spent for the intervals<br/>
      - Test case: displays a chart with the filtered intervals and mean time spent<br/>
    - Test case: when intervals are empty<br/>
      - Test case: does not calculate the mean time spent<br/>
      - Test case: displays a chart with no intervals<br/>
 
20. Test <code>`calculate_key_chart_information`</code> method:<br/>
    - Test case: when given intervals are all above the threshold<br/>
    - Test case: when given intervals contain values below the threshold<br/>
 
21. Test <code>`calculate_mean`</code> method:<br/>
    - Test case: when given an array of intervals and interval precision<br/>
      - Test scenario 1: returns the mean of the intervals rounded to the specified precision<br/>
      - Test scenario 2: returns the mean of the intervals rounded to the specified precision<br/>
      - Test scenario 3: returns the mean of the intervals rounded to the specified precision<br/>
 
22. Test <code>`calculate_variance`</code> method:<br/>
    - Test case: when given an array of intervals and interval precision<br/>
      - Test scenario 1: returns the variance of the intervals rounded to the specified precision<br/>
      - Test scenario 2: returns the variance of the intervals rounded to the specified precision<br/>
      - Test scenario 3: returns the variance of the intervals rounded to the specified precision<br/>
      - Test scenario 4: returns the variance of the intervals rounded to the specified precision<br/>
 
23. Test <code>`calculate_standard_deviation`</code> method:<br/>
    - Test case: when given an array of intervals and interval precision<br/>
      - Test scenario 1: returns the standard deviation rounded to the specified precision<br/>
      - Test scenario 2: returns the standard deviation rounded to the specified precision<br/>
      - Test scenario 3: returns the standard deviation rounded to the specified precision<br/>
 
24. Test <code>`list_review_submissions`</code> method:<br/>
    - Test case: when review submissions are available<br/>
    - Test case: when review submissions are not available<br/>
 
25. Test <code>`review_submissions_available`?</code> method:<br/>
    - Test case: when both team and participant are present<br/>
    - Test case: when team is nil and participant is present<br/>
    - Test case: when team is present and participant is nil<br/>
    - Test case: when both team and participant are nil<br/>
 
26. Test <code>`list_hyperlink_submission`</code> method:<br/>
    - Test case: when the response map ID and question ID are valid<br/>
      - Test case: returns the HTML code for a hyperlink if the answer has a comment starting with 'http'<br/>
      - Test case: returns an empty string if the answer does not have a comment starting with 'http'<br/>
    - Test case: when the response map ID or question ID is invalid<br/>
      - Test case: returns an empty string if the response map ID is invalid<br/>
      - Test case: returns an empty string if the question ID is invalid<br/>
 
27. Test <code>`calculate_review_and_feedback_responses`</code> method:<br/>
    - Test case: when author is a member of a team<br/>
    - Test case: when author is not a member of a team<br/>
 
28. Test <code>`feedback_response_map_record`</code> method:<br/>
    - Test case: when author is provided<br/>
      - Test case: retrieves response records for each round<br/>
      - Test case: calculates feedback response map records for each round<br/>
 
29. Test <code>`get_certain_review_and_feedback_response_map`</code> method:<br/>
    - Test case: when author has feedback response maps<br/>
    - Test case: when author does not have feedback response maps<br/>
    - Test case: when review response maps exist for the given reviewed object and reviewee<br/>
    - Test case: when review response maps do not exist for the given reviewed object and reviewee<br/>
    - Test case: when review responses exist for the given review response map ids<br/>
    - Test case: when review responses do not exist for the given review response map ids<br/>
    - Test case: when review responses exist<br/>
    - Test case: when review responses do not exist<br/>
 
30. Test <code>`css_class_for_calibration_report`</code> method:<br/>
    - Test case: when the difference is 0<br/>
    - Test case: when the difference is 1<br/>
    - Test case: when the difference is 2<br/>
    - Test case: when the difference is 3<br/>
    - Test case: when the difference is greater than 3<br/>
 
31. Test <code>`initialize`</code> method:<br/>
    - Test case: when initializing a new instance of the class<br/>
      - Test case: sets the participants attribute to the provided value<br/>
      - Test case: sets the teams attribute to the provided value<br/>
      - Test case: sets the review_num attribute to the provided value<br/>
 
32. Test <code>`reviews_per_team`</code> method:<br/>
    - Test case: when there are 10 participants, 5 teams, and each participant needs to review 2 times<br/>
    - Test case: when there are 20 participants, 4 teams, and each participant needs to review 3 times<br/>
    - Test case: when there are 8 participants, 2 teams, and each participant needs to review 4 times<br/>
 
33. Test <code>`reviews_needed`</code> method:<br/>
    - Test case: when there are no participants<br/>
    - Test case: when there is one participant and review number is 3<br/>
    - Test case: when there are three participants and review number is 2<br/>
    - Test case: when there are five participants and review number is 4<br/>
 
34. Test <code>`reviews_per_student`</code> method:<br/>
    - Test case: when there are no reviews<br/>
    - Test case: when there is only one review<br/>
    - Test case: when there are multiple reviews<br/>
 
== Design Pattern ==
During our code refactoring process, we leveraged various design patterns to enhance readability and maintainability. One commonly applied pattern was "Extract Method," where we identified lengthy and intricate methods and extracted segments of functionality into separate methods. This restructuring made the code more comprehensible and easier to grasp by isolating specific tasks within dedicated methods.
 
Additionally, we addressed the issue of excessive conditional statements by employing the "Refactoring Conditionals" design pattern. Instead of cluttering the code with numerous conditionals, we refactored by encapsulating the logic within these conditionals into distinct methods. By doing so, we streamlined the code's flow and improved its readability, making it clearer to understand the purpose and execution of each segment.
 
== Relevant Links ==
* '''Github Repository:''' https://github.com/sahilchanglani/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2764
 
== Team ==
=== Mentor ===
* Ananya Mantravadi  (amantra)
 
=== Team Members ===
* Ravi Ghevariya (rghevar)
* Manan Patel (mrpatel8)
* Kanishk Harde (knharde)

Latest revision as of 18:13, 24 April 2024

Team

Mentor

  • Ananya Mantravadi (amantra)

Team Members

  • Ravi Ghevariya (rghevar)
  • Manan Patel (mrpatel8)
  • Kanishk Harde (knharde)

Relevant Links

Expertiza Background

Expertiza is a Ruby on Rails framework-based open-source web application. It is kept up by NC State University employees and students. With the help of this program, instructors can fully manage the assignments and responsibilities assigned in their classes. Expertiza provides many strong features, such as subject addition, group creation, and peer review administration. It is a flexible platform that can manage many kinds of tasks. Users can consult the Expertiza wiki to get more in-depth details about the many capabilities that Expertiza offers.

About Helper

The Ruby on Rails review_mapping_helper module offers a number of helper methods to make the peer review process easier in assignments. It has the capacity to calculate review scores, manage submission statuses, generate review reports, and visualize review metrics; however, it needs to be refactored in order to make the code more readable and maintainable.

Problem Statement

The existing codebase derived from E2301 suffers from lack of clarity, violating the Expert pattern, and inefficient methods, hindering code understandability and maintainability. Key issues include convoluted data handling in views, unclear color-coding methods, and inefficient sorting functions. Additionally, redundant methods and unclear feedback_response_maps further obscure the code's purpose.

Tasks

1. Refactor get_data_for_review_report to use partials for clearer code in views/reports.
2. Refactor color-related methods for clarity and consistency, using American spelling.
3. Rename methods starting with "get" to adhere to Ruby conventions.
4. Update get_awarded_review_score to utilize standardized score-calculation code.
5. Generalize sort_reviewer_by_review_volume_desc for sorting by various metrics.
6. Extracting chart-generating methods into their own module or evaluating the necessity of list_review_submissions
7. Review and clarify the purpose of feedback_response_maps methods.
8. Add comments or refactor small classes for clarity and documentation.

Phase 1

We have concentrated our efforts on addressing the following difficulties throughout the project's first phase:
1. Refactor get_data_for_review_report to use partials for clearer code in views/reports.
2. Refactor color-related methods for clarity and consistency, using American spelling.
3. Rename methods starting with "get" to adhere to Ruby conventions.
8. Add comments or refactor small classes for clarity and documentation.

Phase 2

We have planned our efforts on addressing the following difficulties throughout the project's second phase:
4. Update get_awarded_review_score to utilize standardized score-calculation code.
5. Generalize sort_reviewer_by_review_volume_desc for sorting by various metrics.
6. Extracting chart-generating methods into their own module or evaluating the necessity of list_review_submissions
7. Review and clarify the purpose of feedback_response_maps methods.


Implementation

Phase 1

Refactor the `get_data_for_review_report` method

Refactor the `color-related` methods

Rename methods starting with `get` to adhere to Ruby conventions methods

Design Pattern

The Refactoring pattern is essential to enhance code readability, maintainability, and adherence to best practices. By systematically restructuring code components, eliminating redundancies, and applying standard conventions, the Refactoring pattern ensures improved code quality and easier future modifications.

Plan of work

We began our work by examining the review_mapping_helper.rb file to understand its connection to the rest of the codebase. We then had detailed discussions with our mentor about the project's flow and structure. We organized our project requirements by difficulty levels, assigned tasks among the team, and began refactoring existing methods and creating new files as needed. We made sure to preserve the integrity of existing test cases while adding new ones where needed.

Project 4 - DESIGN DOC

We have been assigned below-cited changes to do after project 3

4. Refactoring get_awarded_review_score Method:

  • Standardize the score-calculation logic to ensure consistency and readability.
  • Break down complex calculations into smaller, more understandable components.
  • Improve method documentation and clarity to enhance understanding.

5. Generalizing sort_reviewer_by_review_volume_desc:

  • Modify the method to accept flexible sorting metrics, enabling customization based on various criteria.
  • Update method documentation to reflect the changes and provide usage guidelines.

6. Code Organization Enhancements:

  • Extract chart-generating methods into separate modules or classes for better organization and reusability.
  • Evaluate the necessity of list_review_submissions method based on insights from the Expertiza wiki and refactor accordingly.

7. Documentation and Clarity Improvements:

  • Review methods related to feedback_response_maps and add comments or refactor small classes to enhance clarity and documentation.
  • Ensure consistent naming conventions and adherence to coding standards throughout the codebase.

This section contains changes and contributions to Project 4

Issue #4: Method get_awarded_review_score needs to be refactored

  • Methods involved: get_awarded_review_score
  • Solution:After addressing Issue 2, the method was renamed to determine_awarded_review_score to align with Ruby conventions. Additionally, redundant instance variable settings were moved inside the loop to streamline the code. The explicit nil or -1.0 checks were eliminated and integrated into the instance_variable_set line.
  • Changes



Issue #5: The method sort_reviewer_by_review_volume_desc should be generalized so that it can sort by any metric, not just review volume. Other metrics might include number of suggestions, or number of suggestions + number of problems detected. This method should not be counting the number of review rounds! Since other places in the code will need to know the number of review rounds, it should be calculated somewhere else in the system.

  • Methods involved: sort_reviewer_by_review_volume_desc
  • Problem: The current function, sort_reviewer_by_review_volume_desc, arranges reviewers in descending order based solely on review volume. This limited approach means it can't be applied to sorting by other metrics.
  • Solution:The idea is to create a more versatile approach by changing the name of sort_reviewer_by_review_volume_desc to sort_reviewer_desc and allowing a metric argument for sorting reviewers, as demonstrated below. This modification was also applied to the review_report section where it was originally used.
  • Changes





Issue #6: make a separate file for for chart related elements in review_mapping_helper.rb

  • Methods involved: display_volume_metric_chart(), display_tagging_interval_chart()
  • Previous Code: The methods mentioned used to be included in the review_mapping_helper.rb file, but they should have been in their own helper file.
  • Problem: These techniques carry out comparable functions in creating graphs and can be implemented as either distinct modules or mixins. Additionally, each method contains more than 30 lines, making them excessively lengthy.
  • Solution: Created new module named 'Charts' withinthe same file. This way the chart helper methods are separated from review_mapping_helper where they are out of place and difficult for any developer to find.
  • Changes





Issue #7: Several methods for feedback_response_maps, check docs to manage this confusion

  • Methods involved: feedback_response_for_author()
  • Previous Code: previous code had an ambiguous variable name
  • Problem: The purpose of the variable was unclear.
  • Solution: Rename the variable to enhance its clarity and provide comments to explain its purpose clearly.
  • Changes



Test Plan

This project involves refactoring, meaning that the original functionality should remain unchanged. Tasks included adding comments to existing code, altering variable names, and similar adjustments that didn't affect the test cases. When method names were modified or moved to different files, corresponding changes were made in the relevant RSpec files. All test cases passed successfully, indicating that the refactoring didn't break the existing functionality.


The image below shows the test cases are passing as well as most of the code climate issues were resolved.

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2406_Refactor_review_mapping_helper.rb&oldid=156890"