E1913 refactor review mapping helper: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 166: Line 166:


==Testing==
==Testing==
===Manual Testing===
===Manual Testing===
''To be carried out''


===RSpec Testing===
===RSpec Testing===


Given below are the tests which are written for the functions that are modified:
Given below are the tests which are written for the functions that are modified:
''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.
==References==
1) https://www.rubyguides.com/2015/12/ruby-refactoring/
2) http://rspec.info/documentation/3.8/rspec-core/
3) http://wiki.expertiza.ncsu.edu/index.php/Main_Page

Revision as of 02:39, 26 March 2019

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

The review_mapping_helper.rb has multiple functions with a wrong naming convention, they are classic examples of bad function names. These functions are to be refactored accordingly. Few of the variables names used in the method must also be refactored to make it more relevant and understandable. In addition, some function's code is to be optimized to ensure that it follows DRY principle. Tests must be written for the functions which are modified. Also, comments must be added to all functions of the file. The create_report_table_header function contains HTML code which should be ideally placed in the view as partials, which will allow to easily reuse the code in Rails application.

Implementation

Flowchart

                                                                          


Refactored method names

All the method names that are refactored are mentioned below-

Before:

 get_each_round_review_and_feedback_response_map_for_feedback_report

After:

 get_each_review_and_feddback_response_map


Before:

 get_certain_round_review_and_feedback_response_map_for_feedback_report

After:

 get_certain_review_and_feedback_response_map


Before:

 get_team_name_color_in_review_report

After:

 get_team_color


Before:

 get_current_round_for_review_report

After:

 get_curr_round


Before:

 get_each_round_score_awarded_for_review_report

After:

 get_awarded_review_score


Before:

 get_min_max_avg_value_for_review_report

After:

 get_review_metrics

Comments added to various functions

There were several methods which didn't have any comments or the comments weren't meaningful. In all those cases, comments have been added or changed which are mentioned as follows:

  # gets the review score awarded based on each round of the review
  def get_each_round_score_awarded_for_review_report(reviewer_id, team_id)
  # gets minimum, maximum and average value for all the reviews
  def get_min_max_avg_value_for_review_report(round, team_id)
  # sorts the reviewers by the average volume of reviews in each round, in descending order
  def sort_reviewer_by_review_volume_desc
  # displays all the average scores in round 1, 2 and 3
  def display_volume_metric(overall_avg_vol, avg_vol_in_round_1, avg_vol_in_round_2, avg_vol_in_round_3)
  # moves data of reviews in each round from a current round
  def initialize_chart_elements(reviewer)
  # The data of all the reviews is displayed in the form of a bar chart
  def display_volume_metric_chart(reviewer)
  # For assignments with 1 team member, the following method returns user's fullname else it returns "team name" that a particular reviewee belongs to.
  def get_team_reviewed_link_name(max_team_size, response, reviewee_id) 
  # if the current stage is "submission" or "review", function returns the current round number otherwise 
  # if the current stage is "Finished" or "metareview", function returns the number of rounds of review completed
  def get_current_round_for_review_report(reviewer_id)
  # gets the response map data such as reviewer id, reviewd object id and type for the review report
  def get_data_for_review_report(reviewed_object_id, reviewer_id, type)
  # gets the team name's color according to review and assignment submission status
  def get_team_name_color_in_review_report(response_map)
  # checks if a review was submitted in every round and gives the total responses count
  def response_for_each_round?(response_map)
  # returns hyperlink of the assignment that has been submitted on the due date
  def submitted_hyperlink(round, response_map, assignment_created, assignment_due_dates)

Function placed in the view as partials

The following function 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

Testing

Manual Testing

To be carried out

RSpec Testing

Given below are the tests which are written for the functions that are modified:

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.


References

1) https://www.rubyguides.com/2015/12/ruby-refactoring/ 2) http://rspec.info/documentation/3.8/rspec-core/ 3) http://wiki.expertiza.ncsu.edu/index.php/Main_Page