[FEATURE]: Refactor God Classes

[Tgenz1213]

Feature summary

Initial discussion for refactoring several design choices to promote better maintainability of the repo

Feature description

AIHawkEasyApplier and AIHawkJobManager are two god classes that are tightly coupled and have too many responsibilities. While they keep related code in the same place, it is difficult to navigate and make any significant changes.

Why does it matter?

1. We can do this voluntarily now, or be forced to do it in the future when the project grows and becomes impossible to manage.
2. Improved testability and maintainability.
3. It will make development significantly easier by working with smaller files and classes.

What does "done" look like?

1. All classes have a single responsibility
2. No more tight coupling
3. Basic amount of testing implemented for all new classes
4. All files are organized
5. Updated docs

Recommendation

Tasks

1. Decide what design features to change
2. Ensure testing for current implementation is complete to prevent regression
3. Ensure there is a plan for rollbacks
4. Update docs, maybe add a simple style guide to help with format/linting config
5. Ensure CI/CD workflows are updated for thorough testing
6. Create tests for new classes
7. Full-stop on new features and fixing non-urgent bugs, freeze PR submissions, make necessary announcements (may be beneficial to freeze PRs earlier to avoid causing excessive merge conflicts)
8. Incrementally move logic to new classes, starting with logic that is not tightly coupled in the old classes
9. Perform testing
10. Open PRs back up for submission

Design changes

• POM Pattern for managing pages to separate logic for each page, increasing testability and maintainability. Say LinkedIn takes a page away or adds a new one - we'll have to change one file to adjust while the rest of the pages unphased.
• Repository Pattern to abstract data access from business logic, improving code organization and separation of concerns
• Service Layer Pattern to tie together POM, repository, and LLM integration, eliminating the need for an overly complex Facade Pattern
• Drop Facade Pattern to remove tight coupling between LLM model and other classes
• Separate files for classes that benefit from separation (not entirely necessary, but looks better IMO than having multiple classes in the same file if one doesn't help the other)

Folder structure

Auto_Jobs_Applier_AI_Agent/

• README.md
• ... (other base-level files, assets/, tests/, .github/, etc.)
• data/
  • example/
    • config.yaml
    • plain_text_resume.yaml
  • config.yaml
  • secrets.yaml
  • plain_text_resume.yaml
  • ...
• docs/
  • style_guide.md
  • architecture_design.md
  • workflow_diagrams.md
  • ...
• output/
  • success.json
  • failed.json
  • skipped.json
  • open_ai_calls.json
• pylint_plugins/
  • init.py
  • stylistic_rules.py
  • plugin_config.py (add this to register more than one plugin in .pylintrc)
• src/
  • init.py
  • main.py
  • models/
    • llm_model.py (abstract base class)
    • ollama.py
    • perplexity.py
    • openai.py
    • ...
  • pages/
    • init.py
    • home_page.py
    • login_page.py
    • job_search_page.py
    • job_posting_page.py
    • easy_apply_upload_page.py
    • easy_apply_question_page.py
    • easy_apply_review_page.py
  • services/
    • job_application_service.py
    • selenium_driver.py
  • repositories/
    • job_repository.py
  • utils/
    • log.py

Motivation

For better maintainability, easier feature implementations, and debugging - extends the life of the project and invites more collaboration

Alternatives considered

Other approaches or design patterns may be better than what I recommended. Some changes can be deferred until absolutely necessary.

Additional context

No response

[surapuramakhil]

usefull relevant information

https://github.com/AIHawk-co/Auto_Jobs_Applier_AI_Agent/pull/833/files/8714460592a0991f86a9ef4aa895f1e482f70e03..78972e61182e217b81b8cea0dfa90bac911a5187?diff=split&w=0