Programming

17398 readers

97 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

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 [email protected]

founded 1 year ago

MODERATORS

[email protected]

Linking parts of the codebase such that changing one forces reviewing the other ? (lemy.lol)

submitted 8 months ago* (last edited 8 months ago) by [email protected] to c/[email protected]

51 comments fedilink hide all child comments

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

[–] [email protected] 5 points 8 months ago (1 children)

Have you considered the Required<T> generic?

https://www.typescriptlang.org/docs/handbook/utility-types.html#requiredtype

[–] [email protected] 5 points 8 months ago (1 children)

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

[–] [email protected] 1 points 8 months ago (3 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.

[–] [email protected] 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.

[–] [email protected] 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.

[–] [email protected] 2 points 8 months ago (1 children)

I am still confused about what OP is looking for. Even in typescript, if a new field is added and not used in other places, compilation will fail. Unless OP explicitly marks the field as optional.

There’s also the possibility that the codebase is littered with the “any” keyword (I’m not saying OP is doing it but I’ve definitely seen plenty of codebases that do this). If someone says they’re using typescript but their code is full of “any” keywords, they’re not using typescript. They’re just using plain JavaScript at that point.

[–] [email protected] 0 points 8 months ago (2 children)

if a new field is added and not used in other places, compilation will fail

That's if the field is added but never used. If it is used in some parts of the codebase, but not used / handled in others, compilation will pass. I would prefer that it doesn't. I would prefer that if such a change were to occur, that every part of the codebase that uses that entity is explicitly addressed by the change made.

Again, if there's anything you don't understand, feel free to ask me directly. I do not get notifications when you reply to a comment that isn't mine.

[–] [email protected] 1 points 8 months ago

On thinking about this a bit more, I feel like you may be expecting the system to handle situations where your business requirement needs the new field to be used now, but used to work without this field before. Based on the example you provided, I am imagining something like a getTasksForUser functionality which previously might have just been filtering on userId but if the business now says that this functionality should now return tasks sorted by priority, you expect the system to somehow know the business requirement and force the developer to use this new priority field ?

If that’s what you’re hoping for, the problem is harder to solve although not impossible. Assuming the example as above , you could maybe just inject the priority field at the data access layer . Another way would be to make the modified entity private and expose a facade with helper functions that are exposed. Now when code that previously used to rely on the entity inevitably breaks , you can replace those usages with usage specific functions exposed from the facade and since the entity is now accessible only from the facade, you can easily update all usages within the facade and make sure no one can miss passing the priority field since the entity is private to the facade and all functions in the facade are known to use the new field.

[–] [email protected] 2 points 8 months ago

It still doesn’t make sense. Obviously your whole explanation hinges very heavily on what exactly you mean when you say “not used/handled” . Depending on your specific use case this could mean anything. As with any code related question, there’s only so much that people who haven’t seen your code can do to help. I think the easiest way to avoid this confusion is to just show some code so we are all on the same page about what the issue is.