Description:
Develop an Architectural Decision Record (ADR) to define and document the class structure for organizing common_utils within the new package. This ADR will outline the core classes needed to organize the existing and future (common) utility functions in a modular, scalable, and reusable manner, adhering to best practices in Python and MLOps, generally followed throughout the VIEWS pipeline.
Class Structure: Define each class’s primary purpose and responsibility, specifying clear boundaries to avoid overlaps in functionality. The structure should support modular development, making it easy to maintain and extend.
Examples:
DataUtils: A utility class for functions related to data manipulation (e.g., cleaning, formatting).
FileUtils: For file handling and operations (e.g., reading/writing files, managing directories).
ConfigLoader: A specialized class to load and manage configuration settings, following standard MLOps patterns for flexible configurations.
Class Scope: Clearly define the scope and boundaries of each class. For instance, a DataUtils class should only handle data preprocessing, while a ConfigLoader class focuses strictly on loading and managing configuration settings, avoiding redundancy.
Flexibility and Reusability: Consider the potential need for new classes as the project evolves. Ensure the ADR leaves room for adding future utility classes without disrupting the existing structure.
Objective:
To establish a modular and reusable class structure that organizes utility functions effectively, aligning with Python best practices and MLOps principles for maintainability, scalability, and consistency with the md&d_python_style_guide.
Tasks:
[ ] Review existing utility functions and determine appropriate class groupings.
[ ] Draft the ADR with defined class names, responsibilities, and examples for each class.
[ ] Review with team members familiar with project utilities and MLOps to ensure alignment with scalability and reusability goals.
[ ] Finalize the ADR, linking it to relevant documentation for easy access.
Cannot be solved before:
Create ADR for Class Structure of Utilities
Description:
Develop an Architectural Decision Record (ADR) to define and document the class structure for organizing common_utils within the new package. This ADR will outline the core classes needed to organize the existing and future (common) utility functions in a modular, scalable, and reusable manner, adhering to best practices in Python and MLOps, generally followed throughout the VIEWS pipeline.
The ADR should be consistent with the md&d_python_style_guide and the naming conventions specified as a product of https://github.com/prio-data/views_pipeline/issues/157
should provide guidance on:
Class Structure: Define each class’s primary purpose and responsibility, specifying clear boundaries to avoid overlaps in functionality. The structure should support modular development, making it easy to maintain and extend.
Class Scope: Clearly define the scope and boundaries of each class. For instance, a
DataUtilsclass should only handle data preprocessing, while aConfigLoaderclass focuses strictly on loading and managing configuration settings, avoiding redundancy.Flexibility and Reusability: Consider the potential need for new classes as the project evolves. Ensure the ADR leaves room for adding future utility classes without disrupting the existing structure.
Objective:
To establish a modular and reusable class structure that organizes utility functions effectively, aligning with Python best practices and MLOps principles for maintainability, scalability, and consistency with the
md&d_python_style_guide.Tasks:
Labels:
documentation,ADR,enhancement