this post was submitted on 28 Dec 2024
11 points (67.7% liked)
Programming
17705 readers
3 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 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It definitely is and I wouldn't take this approach mid-way for a project with multiple users and contributors. But it works for my little projects that desperately need me to be the user more than the developer. An example would be a REST API with a few endpoints where the database operations are handled directly in the route handlers uniquely for that specific task.
Organizationally, you don't want your API handler to care about implementation details like database queries. All DB interaction should be abstracted into a separate layer.
Generally API handlers only care about injecting any "global" dependencies (like a database object), extracting the request payload, and dispatching into some lower-level method.
None of this requires generic code. It's just about having a clear separation of concerns, and this can lead to more reusable and testable code.
But I do choose this approach for these problems to not have reusable code on purpose xD I'm not try-harding to rewrite everything for every feature separately, so most of it would be separated and modular, as long as it's required by the initial purpose of the software. However I avoid writing generic and reusable code that only gets rewarded with functional scalability in mind.
And unit testing is honestly not on my list for these kinds of projects. At best I'd write integration tests to challenge the route handlers. But simply using the software is sufficient to cover the predictably unpredictable usage in these cases.
That's a prime example for untestable code (not testable with unit tests/without IO). That might be fine for a tiny experiment, but I'd advise against it for projects of any size, even private ones. Always use a model like MVC, MVVM, three layers (data, business, user) ...
I feel like we should have an in depth talk to better understand the problems you're facing and the line of thinking that motivates your initial request. Unfortunately I currently do not have the time for that. The best I can do now, with the best of intentions, is to advise you to read literature about software development. The trouble is, that I'm not sure what to suggest, because I think there's nothing that fits your premise. Maybe read about library development/reusable code so you better understand what not to make reusable by comparison? So maybe "Reusable Software: The Base Object-oriented Component Libraries" by Bertrand Myer or "Analysis Patterns: Reusable Object Models" by Martin Fowler. Though, both books are more on the old-fashioned side and I wouldn't recommend them if you're not an avid reader and (former) student of computer science.
Thanks for the recommendations. A missing understanding of what needs to be reusable could be a problem. E.g. in my example when I add a DAO-like interface just to implement it for the two entities I have, I invite my future self to add unnecessary features to make more use of that interface and other generic components.