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... |