Tech debt: Config.load() scaling — consider splitting config by service #184
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Background
Found during periodic refactoring review after 5 completed stories.
Problem
As more services are added,
Config.load()patterns may accumulate more fields and env vars. Currently manageable but worth monitoring.Suggested Fix
Consider splitting config into per-service config modules if the number of config fields grows beyond ~15-20, or use a config framework that supports hierarchical config.
Labels
Type: refactor, Priority: low
This has progressed:
Config.load()is now 180 lines of boilerplate with 9 sub-config sections. Created #199 with a concrete fix proposal (generic_load_dataclasshelper). This issue can be closed once #199 is addressed.Resolved by #199 (PR #215). Config.load() boilerplate has been replaced with a generic
_load_dataclass()helper, reducing the method from ~180 to ~30 lines. The scaling concern is no longer relevant.