Do you always decouple everything in your code?
-
I was doing a very simple backend endpoint that query another service in the network. It was just a kind of proxy, that only exists because the client code in the browser can't have the password for that service.
I could do it in a single function, but my coworkers insisted on having the whole pattern of an endpoint resource class, convert the data to a dto and call a service class, this call a client class, convert it's response to a domain "business object" class, then the resource convert this last one to a response DTO.
-
@sockpuppet7 said in Do you always decouple everything in your code?:
Do you always decouple everything in your code?
I try to as a philosophy, but generally everything I write is fairly tightly coupled unless there is an immediate need/advantage to do otherwise. I do go back and make the time to refactor if it starts becoming an issue though. I find it easier to get permission to do that than the other way round.
MVP, or similar, for GUI stuff always though. It just seems to immediately becomes horrifying otherwise.
-
@Cursorkeys So you think in mine anecdote it was worth it? I'm honestly not sure. It feels a lot slower than doing things the chaotic way. But OTOH we spend more time changing than writing new stuff. I can never make my mind about that.
-
@sockpuppet7 said in Do you always decouple everything in your code?:
@Cursorkeys So you think in mine anecdote it was worth it? I'm honestly not sure. It feels a lot slower than doing things the chaotic way. But OTOH we spend more time changing than writing new stuff. I can never make my mind about that.
It doesn't sound like it was TBH, unless there was some other reason your team insisted on it. Personally I've found doing it to the n'th degree like that without an immediate reason (or a clear need in the very immediate future) turns out to be wasted effort. That doesn't excuse sloppy work, but I think the happy medium is closer to tightly-coupled than the other way around.
-
@sockpuppet7
A good rule of thumb is to decouple things that might change independently and tightly couple parts that will always change at the same time. This doesn't cover everything (sometimes you want to decouple systems for architectural reasons even if you cannot imagine them changing independently ATM), but it's a good general guideline.Edit: In your case, can you imagine that the internal API will change, but that the external API might have to stay the same for legacy applications? Then decoupling is definitely a good idea. Also, it sounds like your co-workers may be trying to adhere to Uncle Bob's "clean architecture", which often requires additional work, but is a good framework in general.
-
@sockpuppet7 Fuck them. Use one function. Make it work. Use it some in the wild. Then you'll start seeing how to even decouple it properly. Otherwise you're bound to rewrite it anyway. Save some hassle.
-
@sockpuppet7 said in Do you always decouple everything in your code?:
I could do it in a single function, but my coworkers insisted on having the whole pattern of an endpoint resource class, convert the data to a dto and call a service class, this call a client class, convert it's response to a domain "business object" class, then the resource convert this last one to a response DTO.
In general, having the extra decoupling makes it easier to test things, and that's usually a reasonable plan since it both lets you check that you're doing your part correctly without impacting on the other service, and helps isolate your code from trouble when the other service decides to change itself. But sometimes it's overkill too; all too often, all the extra boilerplate does is slow everything down and actually make it harder to follow the remote service. So actually it sometimes requires thought and instincts and experience to work out what should be decoupled and what shouldn't…
-
@sockpuppet7 said in Do you always decouple everything in your code?:
endpoint resource class, convert the data to a dto and call a service class, this call a client class, convert it's response to a domain "business object" class, then the resource convert this last one to a response DTO
-
OK, here's my attempt at a serious answer:
If you don't need an abstraction layer now, and there's no indication that you will need it in the future, then it literally doesn't do anything useful.
If your code is clean, it will take "future you" the same work to add it when necessary that it takes present you to add it now.
If "technical debt" is when you avoid doing something that you need, would doing something that you don't need be "technical surplus"?
-
@anonymous234 said in Do you always decouple everything in your code?:
If "technical debt" is when you avoid doing something that you need, would doing something that you don't need be "technical surplus"?
You could call it that, but I think the industry settled on YAGNI instead.
-
@Cursorkeys said in Do you always decouple everything in your code?:
MVP, or similar, for GUI stuff always though. It just seems to immediately becomes horrifying otherwise.
I'm a terrible GUI dev, then; I do webdev for an internal site, and I usually end up writing a store class with both business logic & business data. It's great right up until the moment that you realize that you're passing the entire store to low-level components that only need access to ~10% of the store. (Of course, I have >20 components, and each one accesses a different, overlapping 10%...)
I have a decent collection of reusable, generic components, but when I need a new component, I tend to build it for that one workflow I'm using it in (and, often, have it depend on that store class), and then worry about reusability later.
-
@wft said in Do you always decouple everything in your code?:
Fuck them. Use one function.
I need to get 2 other team members to approve any pull request. People were working on these services for a few years were I was doing other stuff alone, so I can't change everything overnight. But I don't like anything they're doing, I have an irrational hate of cargo cultism.
-
@sockpuppet7
Are you the only dev working on the endpoint/component? If you have collaborators working on the same endpoint but different components, it makes perfect sense for them to get you to decouple everything so your collaborators can get to work as soon as possible without waiting for your implementation. If you are alone working on that endpoint, just fuck it and refactor when you need to later.
-
No, I dont always decouple things. In fact, a year ago, I did exactly what you're doing right now, and I just take the response I get from the internal system and dump it out to the browser without touching it. I needed the service up and running really fast, and there was no need to fiddle with the data.
However, now that people are starting to wish for features that require changing the data in that structure, I am going to split it up with proper DTOs and an interface that I define on my end just to save any future headaches. But when I first did it, there was no need for anything fancy and I am a strong believer in that you should write code to solve the problem you have NOW. The future will always look different, and if you try to write code for future requirements, the extra complexity will almost never fit with what the future actually turns out to need so you'll have to rewrite more complex code to make shit work in the future instead.Keep It Simple, Stupid.
-
@Carnage said in Do you always decouple everything in your code?:
The future will always look different, and if you try to write code for future requirements, the extra complexity will almost never fit with what the future actually turns out to need so you'll have to rewrite more complex code to make shit work in the future instead.
Hear hear! I made a vendor system capable of making every player able to create stores and add products to said stores dynamically and at will. Has it ever fully made it into the game? NOPE!
It's there... if ever someone wanted to make use of it. But seeing as I'm the only guy now, even though I could put it in, I probably won't (soon) as it's not a small effort to translate API requests into in-game things...
-
@sockpuppet7 You nailed it with cargo cultism. It's the same mentality that requires every window/page to have a dozen support files because dur hur seperashun uv cuncurnz.
I always start with one static function. The last thing you need while debugging is a dozen layers of boilerplate for whatever's going on to get lost in. Once it's actually working, then you can part it out, but only if it makes sense to do so, not to appease some arbitrary style cop.
