this post was submitted on 03 Mar 2024
29 points (100.0% liked)

Programming

423 readers
9 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] Fal@yiffit.net 1 points 8 months ago (1 children)

every user of the type must explicitly either use it or explicitly declare that it won’t

What? How does someone declare that they won't use a type? What does that even mean?

Do you have an example use case that you're trying to solve? What additional type are you adding that would break existing users usage? If that's the case, maybe use an entirely different type, or change the class name or something

[–] matcha_addict@lemy.lol 2 points 8 months ago (1 children)

I gave an example use case in the main post, but I'll summarize it again here:

Suppose we have a to-do task manager. A task is an important entity that will be used in many parts of our codebase.

Suppose we add a new field to this task entity. For example, let's say we now added a priority field in our task that previously didn't exist, so users can define if a task is high priority.

The problem: this task entity is being used in many parts or our codebase. How do we make sure that every one of those parts that needs to use the new field does use it? How do we make sure we don't miss any?

I hope this makes sense. If it doesn't, feel free to ask any questions.

[–] spartanatreyu@programming.dev 5 points 8 months ago (1 children)
[–] matcha_addict@lemy.lol 5 points 8 months ago (1 children)

Thanks for the tip! I think that is indeed what I need. Thank you :)

[–] Fal@yiffit.net 2 points 8 months ago (2 children)

Oh are you talking about creating the object? Yeah I think you might get better answers in a TS thread, because that question and the response here makes no sense in most statically typed languages.

[–] matcha_addict@lemy.lol 1 points 8 months ago

If there's anything that doesn't make sense in my question, feel free to ask any questions or clarifications on any part of it.

[–] expr@programming.dev 1 points 8 months ago

Yeah, in most statically-typed languages this is simply the default behavior unless you specifically declare a field as optional.