36
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Mar 2024
36 points (90.9% liked)
Programming
17314 readers
231 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
Most languages have an IDE which will manage the import of that object and when you rename incorrectly, it'll flag it up. If you're calling an incorrect function or variable, it'll flag it etc. Many will have refactoring tools so when you rename something through this, it'll rename all instances of that.
This is related to what I discussed in the "Searching" section. Entity fields may not be necessarily imported, so they would not be caught in this. Say you're using that field's name in a SQL query, HTTP or GraphQL request / query. This may also not be caught by IDE.
This also would not cover the case where a field is modified without necessarily changing its name, or a new field is added and now the code using that entity is not using the field.
Usually when you change your database structure, you would change the object that this is mapped into. If you were to change one without the other, that would be a monumental developer oversight. Adding a field without using it in many frameworks wouldn't necessarily break it, so it wouldn't be a bad change per se.
Any change you make to persistence should reflect as a bare minimum, the object data gets mapped into. This would likely be part of the same branch, and you probably shouldn't merge it until it's complete.
You're looking for tooling to protect you from human errors, and nothing is going to do that. It's like asking, how can I stop myself from choking when eating. You just know to chew. If this isn't obvious, it's a good lesson in development. Make one change at a time and make it right. Don't rush off to presentation changes or logic changes until your persistence changes are complete. When you get into habits like this, it becomes steady, methodical and structured. Rushing is the best way to make mistakes and spend more time fixing them. Less haste, more speed.
For example, if I add a new field. I'd write the SQL, run it, populate a value, get that value and test it. Then I'd move on to the object mapping. I'd load it into the code, and get a bare minimum debug out to see it was loaded out, etc. etc.. Small tweak, test and confirm, small change, test and confirm. Every step is validated so when it doesn't work, you know why, you don't guess.