E1837 refactor review mapping controller

From Expertiza_Wiki
Revision as of 22:33, 28 October 2018 by Dwgoslen2 (talk | contribs)
Jump to navigation Jump to search

Background

At the heart of Expertiza is the ability to review the work of other teams and review your own teammates.The Review Mapping Controller is at the heart of coordinating all of the necessary steps to assign reviews in various ways to specific students or teams.

As such, this controller has become rather large and unmaintainable over time as new types of reviews and review assignment strategies are created. The purpose of this work is to improve the maintainability of this controller based on the goals listed below.

Goals

- separation of concerns
- removed unused methods
- properly group like methods
- remove unused controller methods
- remove SQL statements from the controller into models/helpers where applicable


New Helpers

As part of refactoring, we have introduced several new Helper classes and methods.

Report Formatter Helper

This helper now contains isolated methods for each report type that needs to be built from the controller. This helper is implemented as a module, so any/all instance variables are added to the class including it. This allows us to keep the controller logic very small but still populate all needed values for the report views.


Strategy Pattern for Automatic Review Mapping

The previous implementation for the Automatic Review mapping method (automatic_review_mapping) was lengthy and overrode specific arguments within the Automatic Review Mapping Strategy method (automatic_review_mapping_strategy) before actually assigning reviews. We decided to implement an actual Strategy pattern here.

We created a simple ReviewStrategy class with the following subclasses:

- StudentReviewStrategy
- TeamReviewStrategy

Each of these strategies determines the number of reviews per team, the number of reviews per student, and the total number of reviews needed. After implementing this pattern, we were able to simply use the methods provided on the ReviewStrategy class in the algorithm that assigns reviews with minimal refactoring.


Below is a simple UML diagram of these new classes:

Removed SQL

Several methods had raw SQL, or at the very least SQL-like statements. Where possible, these calls were pushed down into their respective models.

Start Self Review

This method had the following SQL

SELECT t.id as t_id FROM teams_users u, teams t WHERE u.team_id = t.id and t.parent_id = ? and user_id = ?

It was migrated to be a scope inside of the Team model.

Removed Methods

We were able to remove the following methods that were either obsolete or had functionality that could be refactored into other methods.

- execute_peer_review_strategy: This functionality simply performed a check that is now in automatic_review_mapping