4 ms·
Are you evaluating the points made by James from your context and limiting your understanding? If you work for a company where software is not a differentiator
by justesjc 4y ago
Are you evaluating the points made by James from your context and limiting your understanding? If you work for a company where software is not a differentiator, but a cost to doing business, then using frameworks, DI or not, is probably the right thing to do. But if your code is a core part of the business, you probably don't want to give control to some third party that may screw you.
All successful companies that I have worked for where the code is core to the business, rolled most of their own software (NPM for the web aside). Long term you need that control, understanding and speed of change if required.
- rektide 4y agoWhat major upheaval examples should we fear? DI frameworks seem quite reloable, trustworthy, & consistent. I cant think of any examples of a community being burned by trusting their framework. I cant think of any cases or blogs where someone has been left up a creek, has ended up hard clashing with their framework I dont see what justifies this fear, uncertainty, and doubt.
- oezi 4y agoYes, I evaluate it from the perspective of developing enterprise software where I need to designate extension points for a fluid number of team members. Only using CI can I balance the flexibility of offering the interfaces people need with the oversight needed. Also just develop your own DI if you consider it business critical but not yet commodity (you don't do your own logging/crypto/math libs, right?).