4 ms·
From a decade of software engineering and architecture I'd say these are some excellent guidelines for when to choose a library. Let me follow up with a collect
by endymi0n 9y ago
From a decade of software engineering and architecture I'd say these are some excellent guidelines for when to choose a library. Let me follow up with a collection of the cases where I'd absolutely stay away from libraries:
1. Your standard library can do it. Whatever you do, RTFM, learn your language inside out and prefer the standard library for whatever you do, even if it looks a little worse — especially if it's not more than 50% more code than using a library for convencience functions. This already goes 80% of the way to prevent "left-pad"-like disasters.
2. Everything that is your core business logic. Don't succumb to the fascination of rule engines and state machine builders. Just write that damn code yourself, future you will be way happier for it.
3. If you're sure that you'll never need more than 10-20% of a library, but eventually will need something considerably different starting from there. This may be grounds for justifying building your own one. If you do that and it doesn't give your business a unique edge, consider open sourcing it from the start.
4. If in doubt, rather stay away from big, fat frameworks until they give you a really big edge (like in Frontend development) or you tend to do a lot of rinse-and-repeat stuff. They tend to solve a lot of your problems, but rot fast and you have to continuously keep up with the Kardashians.
- icebraining 9y agoRegarding (1), can't say I agree; by all means, know your stdlib well, but if you still wonder if you need a library, and there's one with a lot of traction, I'd just use it. left-pad is a red herring - the problem there was poor dependency management, not the use of the library itself.