CSC/ECE 517 Spring 2015/oss E1501 YWS

E1501: Refactoring Assignments.rb

<ref>Refactoring</ref>Refactoring is a technique to alter the internal structure of the code without affecting the external behaviour. It is used for:

• Programs that are difficult to read;
• Programs that does not follow the language specific guidelines;
• Programs that has high coupling;

Introduction to Expertiza

<ref>Expertiza</ref>Expertiza is an open source project developed using the Ruby on Rails platform. It provides features like team assignments, peer review, submission of projects, grading etc. The code can be cloned and modified from GitHub. This application provides an efficient way to manage assignments, grades and reviews.

Assignment.rb is the largest class in Expertiza, comprising 1105 lines of code which contains the assignment model and the related functionalities. It also contains the score module which is refactored to make the file more clean and easy to read.

Problem Statement

Classes involved:

assignment.rb
scorable.rb
Gemfile
schema.rb

What they do

Assignment.rb along with the controller file is responsible for creating and editing the assignments. The file also contains methods which calculates the student scores. The assignment and scoring modules are very tightly bound which can be grouped into smaller, more manageable classes.

What needs to be done:

• The assignment model needs refactoring as it contains some modules which are responsible for generating assignment scores;
• Moreover, the querying module is database dependent which should be made database independent;
• There are many function names and code lines which does not follow the ruby guidelines. They should be changed to more ruby like coding style;

Re-factored Instances

Instance 1 : Refactoring the Assignment.rb

Creation of separate module scorable.rb

AvtiveRecord Concern is pattern introduced in Rails 4.1 to seperate the heavy loading done by models. It is recommended that models should be fat and should contain the business logic. This is leads to models getting too coupled. ActiveRecord Concerns solves this problem. Methods which can be logically put together are added in a module/mixin. This mixin is then included in the main model. The mixin can be reused by any other model if required. This makes the code align with Rails philosophy of DRY. In this case all methods related to 'scores' were collaborated together and put inside the mixin scorable. There are many methods which are not directly related to assignments. These methods are responsible for generating the scores and related functions. These methods are:

• get_scores;
• get_max_score_possible;
• compute_reviews_hash;
• get_average_score;

All these methods are taken out of assignment.rb and pushed into a new file "scorable.rb". This made score generation a separate module and the dependency of scores on assignments have been reduced significantly.

Instance 2 : Ruby idiomatic

Make assignment.rb more Ruby like

There were many instances where the coding was not like ruby like. The ruby community believes in small, well readable code. The code was refactored to be more readable. Changes such as removing the return statements, writing .each instead of for loop and improving naming conventions were implemented. Few of the examples are given below:

Before Change

 quiz_response_mappings.each do |qmapping|
   if qmapping.response
     quiz_responses << qmapping.response
   end
 end

After Change

 quiz_responses = quiz_response_mappings.select{ |qmapping| qmapping.response }.map(&:response)

Before Change

 total = 0
 self.questionnaires.each { |questionnaire| total += questionnaire.get_weighted_score(self, scores) }
 total

After Change

 self.questionnaires.inject(0) { |total, questionnaire| total + questionnaire.get_weighted_score(self, scores) }

Instance 3 : Addition of ActiveRecord like Query

ActiveRecord provides a layer on top database. Hence if no Mysql specific query is used in the code it very simple to change the database without changing the code. Using Ruby hash for query rather than raw sql also helps in keeping the code clean The queries where changed to function more like active record query. This made the queries database independent and more user friendly.

Before Change

  DueDate.where( ['assignment_id = ? and deadline_type_id >= ?', self.id, 7]).due_at

After Change

  DueDate.where(assignment_id: self.id, deadline_type_id: 7).due_at

Instance 4: Ruby style guide

We used `rubocop` to check the ruby style guide violations. We fixed most of the Ruby style guide violations in that class.

Instance 5 : Changing <ref>Gemfile</ref>Gemfile

• Version of gem "EventMachine" was updated as earlier version was incompatible with ruby version 2.2.0. The version was changed from 1.0.3 to 1.0.7.; The older version was not compatible with ruby 2.2.0

• One more gem "quite_assets" was added to avoid unnecessary log creation of the asset request. This is very helpful during development.;

• Clean up tests: few of the controller tests were not in the correct order.

Steps to verify changes

• We have not made any changes in the features of Expertiza. The changes are checking bad code smells and fixing them. The way to verify the changes is to make sure that it works as it was previously.

See Also

1. Expertiza on GitHub
2. GitHub Project Repository Fork
3. The live Expertiza website
4. Expertiza project documentation wiki

References

<references/>