CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper
Introduction
This page gives a description of the changes made for the review_mapping_helper.rb of Expertiza based OSS project.
Expertiza Background
Expertiza is a web application where students can submit and peer-review learning objects (articles, codes, websites, etc). Instructors add and grade the assignments submitted by students to Expertiza. Students can be assigned in teams based on their selection of the topics. It has functionalities such as peer reviews in which students can provide feedback on other's work which helps peer in better developing the project. It is supported by the National Science Foundation.
Problem Statement
What is needed: This project builds on E2125, and should begin with the refactoring done by that project. That project focused on simplifying the methods in review_mapping_helper, while this project looks at making the code more understandable and transparent.
- Method get_data_for_review_report 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. Doing the same thing with partials in views/reports would make the code easier to follow
- The next three methods involve team “color”. Color-coding is explained on this page and this page for the E1789 project and this page for E1815. The code for these methods is not at all clear, and should be refactored. And please use the American spelling “color”.
- Various method names begin with get. This is not Ruby-like. Change the names to something more appropriate.
- The get_awarded_review_score computes an overall score based upon scores awarded in individual rounds. This is one of many places in Expertiza where scores are being calculated. Score-calculation code for multiple rounds is being standardized now, in response_map.rb. Contact Nicholas Himes (nnhimes@ncsu.edu) for particulars. Change this method to use the new code.
- 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.
- The next several methods generate charts. They are cohesive enough that they should be in their own separate file, either another helper or a mixin.
- There is a method list_review_submissions. It’s not at all clear that this method is needed, though it is used in one view. Look on the Expertiza wiki and see if there is a better way.
- Also there are several methods for feedback_response_maps. It is not at all clear why they are here. Look on the Expertiza wiki for the documentation, and see if you can replace them by calls to other methods, or at least make it clearer what they are doing.
- The file ends with three small classes being defined. There are no comments at all to explain what is being done. Look them up on the Expertiza wiki and refactor or comment them, whichever seems more appropriate.
Implementation
Flowchart
The following process is carried out to complete the project-
Refactoring
Refactoring method
All the method names that are refactored are mentioned below-
review_ get_data_for_review_report
Since this method marshals a lot of data together and passes back a data structure, it is quite difficult to see how the data is being displayed. Therefore what we were thinking is to remove this existing method, create new partials which renders specific data for each individual tasks performed in the current method and pass it to the views file. Similar to what we do Expert pattern.
get_team_colour
Since the method is not particularly clear we will be refactoring the method in such a way that no code is repeated, no conditions is checked multiple times and finally move this piece of code to review_response_maps.rb to decrease the total length of the file (>450 line).
To remove 'get' from the below methods to something ruby like methods( below suggestions are subject to change)
get_data_for_review_report to data_for_review_report get_team_colour to team_colour get_link_updated_at to link_updated_at get_team_reviewed_link_name to team_reviewed_link_name get_awarded_review_score to awarded_review_score get_review_metrics to review_metrics get_each_review_and_feedback_response_map to review_and_feedback_response_map get_certain_review_and_feedback_response_map to certain_review_and_feedback_response_map
Since methods starting with the the word 'get' are not ruby-esque and may cause unintended side-effects, we'll be changing the method names
get_awarded_review_score
This method computes an overall score based upon scores awarded in individual rounds. Since this task is already being done in response_map.rb, we'll using this rb file's method and remove the repeated method from this file.
sort_reviewer_by_review_volume_desc
This method is currently sorting the reviewer using review volume. We'll be generalizing this method such that it takes 1 more additional metrics and sort reviewers using the provided metrics
The below methods
initialize_volume_metric_chart_elements display_volume_metric_chart initialize_review_metrics_chart_elements display_review_metrics_chart prepare_chart_data prepare_chart_options
These methods are specific to to creating and editing charts so they should have their own helper/mixin so we'll be moving these methods out of review_mapping_helper.rb to some other helper/mixin.
list_review_submissions
We'll be understanding and refactoring this method as currently its not known where this method is being used. If we find that this method is not being used, then we'll remove it from the file.
The below methods
get_each_review_and_feedback_response_map get_certain_review_and_feedback_response_map
These methods use 'feedback_response_maps' and its not clear how and where they are used. So our task is to find out how and where these methods are being used and how we can implement it better.
The below classes
class ReviewStrategy
attr_accessor :participants, :teams
def initialize(participants, teams, review_num)
@participants = participants
@teams = teams
@review_num = review_num
end
end
class StudentReviewStrategy < ReviewStrategy
def reviews_per_team
(@participants.size * @review_num * 1.0 / @teams.size).round
end
def reviews_needed
@participants.size * @review_num
end
def reviews_per_student
@review_num
end
end
class TeamReviewStrategy < ReviewStrategy
def reviews_per_team
@review_num
end
def reviews_needed
@teams.size * @review_num
end
def reviews_per_student
(@teams.size * @review_num * 1.0 / @participants.size).round
end
end
Its not known where are being used so we'll be removing these classes or provide better documentation for these classes if their application is found.
Function placed in the view as partials
The following method has been removed from the review_mapping_helper.rb and added to the views as partials:
def create_report_table_header(headers = {})
table_header = "<div class = 'reviewreport'>\
<table width='100% cellspacing='0' cellpadding='2' border='0' class='table table-striped'>\
<tr bgcolor='#CCCCCC'>"
headers.each do |header, percentage|
table_header += if percentage
"<th width = #{percentage}>\
#{header.humanize}\
</th>"
else
"<th>\
#{header.humanize}\
</th>"
end
end
table_header += "</tr>"
table_header.html_safe
end
The following is the code available in views in the file _report_table_header.html.erb:
<% table_header = "<div class = 'reviewreport'><table width='100% cellspacing='0' cellpadding='2' border='0' class='table table-striped'><tr bgcolor='#CCCCCC'>" %>
<% headers.each do |header, percentage| %>
<% table_header += if percentage %>
<% "<th width = #{percentage}> #{header.humanize} </th>" %>
<% else %>
<%"<th> #{header.humanize} </th>" %>
<% end %>
<% end %>
<% table_header += "</tr>"%>
<% return table_header.html_safe %>
Testing
RSpec Testing
RSpec testing was carried out for the methods that had been refactored. Given below are the tests which are written for the functions that are modified:
describe 'My Test Cases' do
before(:each) do
create(:instructor)
create(:role_of_student)
login_as("instructor6")
visit '/tree_display/list'
click_link 'View reports'
expect(page).to have_current_path('/reports/response_report')
click_link 'View'
end
it "can display review metrics", js: true do
expect(page).to have_content('Metrics')
end
it "can display review grades of each round", js: true do
expect(page).to have_content('Score awarded')
end
it "can display review summary", js: true do
expect(page).to have_content('Reviews done')
end
it "can display review summary", js: true do
expect(page).to have_content('Reviewer')
end
it "can display review summary", js: true do
expect(page).to have_content('Team reviewed')
end
end
Manual Testing
To be carried out.
Design Pattern
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.
During the process of refactoring methods as well as method names,Strategy Pattern was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.