Suppose we have a large to-do task manager app with many features. Say we have an entity, which is the task, and it has certain fields like: title, description, deadline, sub-tasks, dependencies, etc. This entity is used in many parts of our codebase.

Suppose we decided to modify this entity, either by modifying, removing, or adding a field. We may have to change most if not all of the code that deals with this entity. How can we do this in a way that protects us from errors and makes maintenance easy?

Bear in mind, this is just an example. The entity may be something more low-key, such as a logged user event in analytics, or a backend API endpoint being used in the frontend, etc.

Potential Solutions

Searching

One way people do this already is by just searching the entity across the codebase. This is not scalable, and not always accurate. You may get a lot of false positives, and some parts of the code may use the entity without using it by name directly.

Importing

Defining the entity in one central place, and importing it everywhere it is used. This will create an error if a deleted field remains in use, but it will not help us when, say, adding a new field and making sure it is used properly everywhere the entity is being used

so what can be done to solve this? plus points if the approach is compatible with Functional Programming

Automated Tests and CICD

Tests can discover these types of issues with high accuracy and precision. The downside is… Well tests have to be written. This requires developers to be proactive, and writing and maintaining tests is non-trivial and needs expensive developer time. It is also quite easy and common to write bad tests that give false positives.

  • jkrtn@lemmy.ml
    link
    fedilink
    arrow-up
    4
    arrow-down
    2
    ·
    9 months ago

    “What’s a technique so woodworkers can make sure their furniture fits together on the first try?”

    “Measuring and marking out the plan before making cuts.”

    “Hmm. No, that sounds tedious and difficult, and requires the woodworker to be proactive. No thank you.”

    • matcha_addictOP
      link
      fedilink
      arrow-up
      1
      arrow-down
      3
      ·
      9 months ago

      Interesting analogy, but it’s probably better to address my point directly instead of arguing about woodworking

      • jkrtn@lemmy.ml
        link
        fedilink
        arrow-up
        3
        ·
        9 months ago

        It’s very clear that you want a magic solution that does what you want without any upfront effort. Please let us all know if you find one.

        • matcha_addictOP
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          9 months ago

          Nothing is without effort. I want something with high confidence. Most organizations fail at testing in one way or another (riddled with false positives, flaky tests, or outright low coverage). Tests are good to have, but they are not enough for what I want.

          magic solution

          If you think type systems are magic, then sure :)

          plesse let us know if you find one

          It looks like I can leverage certain type systems to do this. I might need to work with it more before concluding.