Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stage 2 um2nc Redevelopment - Refactoring & Corrections #138

Open
12 tasks
truth-quark opened this issue Oct 9, 2024 · 0 comments
Open
12 tasks

Stage 2 um2nc Redevelopment - Refactoring & Corrections #138

truth-quark opened this issue Oct 9, 2024 · 0 comments
Labels
project management High level project issues

Comments

@truth-quark
Copy link
Collaborator

truth-quark commented Oct 9, 2024

This step is facilitated with a unit test framework & substantially modularised the codebase for flexibility. Stage #1 development identified several code issues which were deferred to manage project complexity. Some general problems include:

  • Occasional bugs or unexpected behaviour
  • Some algorithms may:
    • Not work as expected
    • Contain dead code branches
  • Dependencies between modules (e.g. um2netcdf is strongly coupled to iris cubes)
  • Reliance on test mocks to manage dependencies
  • Code doesn't use cleaner Python idioms

Step 2 tasks could include:

  • Fix buggy code/algorithms
    • Timing/calendar change functions?
    • No data handling?
  • Address code rework issues of high priority
  • Refactoring:
    • Reduce I/O dependencies
    • Refactor mule ops to constrain usage to specific, separate section of code
    • Extract iris ops as per mule (if possible)
    • Use newer Python idioms for looping, containers, warnings & exceptions
    • Generally simplify the code base
      • Fix complex logic, e.g. cube renaming & time/cal fixes
    • Reorder code into modules & namespaces

Notes on external dependencies:

As of October 2024, um2netcdf is strongly coupled to iris cubes & 'mule. The dependency means um2nchas to change if either of these dependencies change significantly or are discontinued etc. Additionally, themule/iris` dependencies affect the test suite, both mocking the dependencies & their complex data structures.

Goal: work towards a Functional Core, Imperative Shell software architecture, as per Gary Bernhardt's Boundaries: https://www.youtube.com/watch?v=yTkzNHF6rMs talk.

  • Move I/O ops to imperative shell code (the top level code, near the entry points)
    • Avoid I/O ops in low level algorithms, helper functions
    • Pass open file objs
  • Exchange information with data primitives & data structures (not files)
    • Depend on the data, not other files, modules etc
  • The core should be modification functions that only take & return data
    • Manipulating & saving cubes etc should occur out in the imperative shell
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project management High level project issues
Projects
None yet
Development

No branches or pull requests

1 participant