CSC/ECE 517 Spring 2023 - E2325 Further refactoring and improvement of review mapping helper

Introduction and Prior Work

Previously the file review_mapping_helper.rb was refactored according to the requirements mentioned by code climate. On analysis, it was found that the module exceeded the lines of code and several methods in the file had high cyclomatic complexity and assignment branch condition size.

All the issues detected by the code climate analysis were fixed by refactoring the code. All methods were tested for cyclomatic complexity, perceived complexity and assignment branch condition size. Rubocop was used for individually testing all methods and screenshots for successful results were included in the documentation.

Requirements

1. The method get_data_for_review_reports passes a data structure to views/reports/_review_report.html.erb making it responsible for handling data. This violates the Expert pattern which needs to be rectified.

2. Methods involving the term "color" are not clear. Refactor them to make them more understandable.

3. Convert method names to more Ruby-like method names.

4. Use the standardized score calculation code from response_map.rb to compute awarded review score.

5. Generalize the method sort_reviewer_by_review_volume_desc to sort by any metric and separate the logic for number of review rounds.

6. Separate chart-generating methods into a separate file.

7. Refactor method list_review_submission.

8. There is less clarity on some of the methods created, add comments, refactored and made them easier to comprehend.

Design Plan

Implementing Expert Pattern

As mentioned in the requirements, the method get_data_for_review_reports marshals a lot of data together and passes back a data structure. It is used in views/reports/_review_report.html.erb, but it is quite difficult to see how the data is being displayed. It violates the Expert pattern, because the view needs to know how to break apart the structure that is passed to it. We plan on making use of partials to make the code easier to follow

Use updated code

There has been an introduction of logic for score calculation. We need to make use of this standardized logic for score calculation in the method get_awarded_review_score.

Improve method names

Few method names like get_team_color, get_data_for_review_report, get_awarded_review_score need to be changed to more ruby like method names. For e.g. the method name get_data_for_review_report can be changed to review_report_data. This name follows the ruby naming conventions and is concise and clear to understand. This refactoring will be done for all the methods in all the files where these methods are called.

Extract chart generation

There are several methods used for chart generation in review reports. This logic has to be extracted in a separate file. We plan on doing this using another helper file or a mixin.

Generalize Logic

Modify the method sort_reviewer_by_review_volume_desc to generalize it so that it can sort by any metric, not just review volume. It should be able to sort based upon other metrics like 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. For this we can update the sorting logic and take in the parameter which upon which the sorting needs to be done.

Refactoring and Lucidizing code

We plan on refactoring the required methods and add comments, refactor code to make it easier to comprehend and follow.

Proposed Implementation

[[File:]]