Summary
It is likely that this concept of a shared augmentation service will be scrapped, or at the least will not be solely based on this code. Therefore we can make numerous simplifications to this module.
Why
The Augmentation module was designed to be extensible and configurable, i.e, support the ability for other projects to use the same base code. This of course adds lots of complexity, which brings with it the expected risks associated with complexity, which must be compared against the expected benefits. With the creation of Refiner's own augmentation code it is likely that our design assumptions are not even compatible with other project's needs, so even if a shared augmenter was created it would likely have to be designed carte blanche. Therefore is little, if any benefit to continue to use the current structure of our augmentation code.
Scope
There are lots of opportunities for improvement, including but not limited to:
- Removing the ABC
- Augmentation likely does not need to be a class at all, but just a stateless module (or at least a module with state that does not change) with public functions.
- Removing the ability to pass in configurations. We likely still want the service to be configurable (as in configurations in a single location), but it does not need to be so flexible to account for different projects, or be changed on the fly.
Acceptance Criteria
- The augmentation module has been simplified and code quality increased.
Summary
It is likely that this concept of a shared augmentation service will be scrapped, or at the least will not be solely based on this code. Therefore we can make numerous simplifications to this module.
Why
The Augmentation module was designed to be extensible and configurable, i.e, support the ability for other projects to use the same base code. This of course adds lots of complexity, which brings with it the expected risks associated with complexity, which must be compared against the expected benefits. With the creation of Refiner's own augmentation code it is likely that our design assumptions are not even compatible with other project's needs, so even if a shared augmenter was created it would likely have to be designed carte blanche. Therefore is little, if any benefit to continue to use the current structure of our augmentation code.
Scope
There are lots of opportunities for improvement, including but not limited to:
Acceptance Criteria