Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Refactor Training Routes #4366

Open
adamjcolvin opened this issue Jun 11, 2024 · 0 comments
Open

RFC: Refactor Training Routes #4366

adamjcolvin opened this issue Jun 11, 2024 · 0 comments
Labels
refactor Code changes that don't affect any functionality, but make changing the code easier in the future.

Comments

@adamjcolvin
Copy link
Contributor

What We Currently Have

In our database, a Trainee has a training route, which is defined as an integer. We have text values for each of those integers, which we use in the code. These constants, and many others related to them like ROUTE_INITIATIVES are defined in an initialiser called training_routes.

We also have a library class called TrainingRouteManager, which is responsible for answering questions like requires_schools?, requires_degree? etc.

Proposal

  • Change the training_route column in the database to be a string type instead of an integer type. This will remove the need for any mapping with integers, both on our side and on the data side.
  • Move any constants around training routes out of the initialiser and into the Trainee model. This seems like the best place, since the routes are the Trainee's responsibility. We could have a concern on Trainee which has all of these constants, the enum definition itself and any other related logic.
  • Change references to constants like TRAINING_ROUTE_ENUMS to Trainee::training_routes or something similar.
  • Use the enum convenience methods in place of the TrainingRouteManager where possible.
  • Move any remaining logic in the TrainingRouteManager into the new concern.
@adamjcolvin adamjcolvin added the refactor Code changes that don't affect any functionality, but make changing the code easier in the future. label Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Code changes that don't affect any functionality, but make changing the code easier in the future.
Projects
None yet
Development

No branches or pull requests

1 participant