3 ms·
You do need to understand the pros and cons, and wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to
by afro88 2y ago
You do need to understand the pros and cons, and wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces.
I wasn't talking about blindly doing stuff without understanding consequences and risk managing. I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today.
Firewalling all interfaces to dependencies for example can be future tech debt if you need to move fast to stay ahead of competitors, but all the indirection is making development too slow (or causing developers to find other more enjoyable work). Can't imagine working on a React codebase where React is completely abstracted behind our own interfaces to all of it.
- skydhash 2y ago> I was rebutting the point from the article that you shouldn't ever have tech debt. You will, no matter what choices you make today. I agree > wow there are some incredible time and complexity costs to maintaining all dependencies yourself, or trying to firewall all dependencies through interfaces. I'm not saying you should firewall everything. But if it make sense, you do so. You also need someones that understand each core deps enough they can patch it if the maintainers won't resolve an issue (happens more in the npm world). Even with React, you can extract the business logic and reuse it elsewhere. The goal is to avoid depending that much on projects that have less stability than yours (some bad experiences here with React Native). How you do it is contextual, but you should keep it in mind.
- afro88 2y agoAh I see now, you took issue with the example specifically, rather than the point. You're right, I see how it's a bad example, and what you've laid out is a very good way of handling dependencies.