I noticed that `AnnotateRoutes` can be more maintainable by refactoring. I am planning to refactor `AnnotateRoutes` in this order. * separate logic of `AnnotateRoutes` into `AnnotateRoutes::HeaderGenerator`. * add methods to `AnnotateRoutes::HeaderGenerator` and refactor methods. * add `AnnotateRoutes::AnnotationProcessor` and `AnnotateRoutes::RemovalProcessor` The final goal of this refactoring is as follows. * https://github.com/nard-tech/annotate_models/blob/feature/refactor_annotate_routes/processors/lib/annotate/annotate_routes.rb * https://github.com/nard-tech/annotate_models/tree/feature/refactor_annotate_routes/processors/lib/annotate/annotate_routes So in the first I added `AnnotateRoutes::HeaderGenerator` in order to separate logic of `AnnotateRoutes` in this PR. When refactor of `AnnotateRoutes` is finished, I would like to refactor `AnnotateModels` in a like way.
Name |
Last commit
|
Last update |
---|---|---|
.github | Loading commit data... | |
bin | Loading commit data... | |
lib | Loading commit data... | |
spec | Loading commit data... | |
.dockerignore | Loading commit data... | |
.document | Loading commit data... | |
.gitignore | Loading commit data... | |
.overcommit.yml | Loading commit data... | |
.rbenv-gemsets | Loading commit data... | |
.rspec | Loading commit data... | |
.rubocop.yml | Loading commit data... | |
.rubocop_todo.yml | Loading commit data... | |
.travis.yml | Loading commit data... | |
.yardopts | Loading commit data... | |
AUTHORS.md | Loading commit data... | |
CHANGELOG.md | Loading commit data... | |
Gemfile | Loading commit data... | |
Guardfile | Loading commit data... | |
LICENSE.txt | Loading commit data... | |
README.md | Loading commit data... | |
RELEASE.md | Loading commit data... | |
Rakefile | Loading commit data... | |
annotate.gemspec | Loading commit data... | |
potato.md | Loading commit data... |