this post was submitted on 03 Mar 2024
35 points (90.7% liked)

Programming

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



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
[–] [email protected] 10 points 8 months ago (1 children)

If you update your tests to reflect proper usage of the new field then you can catch potential errors.

[–] [email protected] 5 points 8 months ago* (last edited 8 months ago) (3 children)

Automates tests definitely work, but the downside is it requires the developer to be proactive, and the effort put in writing tests is non-trivial (and its easy and common for developers to write bad tests that give false positives).

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

Hmm I think you're looking for a technical solution to a non-technical problem.

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

Sometimes it's possible, I think

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

Depends on what you consider technical. I don't see this as much different than how type systems prevent type errors.

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

Take your example of adding a field to an entity. Just because you've made that code change doesn't mean other code should be using it. Who should be using it and how is determined by the business rules.

Also your interest in ensuring it is "properly" used is impossible to enforce. What's considered proper even for existing code can change over time.

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

doesn't mean other code should be using it.

Yes you're right. Sorry it wasn't clear from what I said before, but that's what I am saying too. The point is, if such a change is made, it should explicitly address every code that uses that entity who just added a new field. When I say "address", I mean that the user must at least be forced to "sign off" and explicitly saying a part of the code does not need to be changed due to this change. One possibility is explicitly declaring that a field is not used.

I hope this makes it clearer.

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

But no matter what you do, you're asking for something that will need to be manually done. Your tests should be done, and they should be reviewed. It will solve the problem you have and many more.

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

Just like type systems prevent you from type errors that you may otherwise write unit tests for, I don't see it unviable to have something that protects from the errors I mention.

In fact I think my solution might be in particular use of the type system, which I am experimenting with right now.

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

Having unit and automated integration tests backed by both requirements and high code coverage. As a lead I can verify that not only you made the change to support the requirements though these unit tests but also a really quick verification that other functionality may not have changed based on your large scale change. Helps a lot for significant refactoring too