Dependencies. What have they done for you LATELY?!
I would never be so bold as to claim that I invented this one from scratch. The ideals behind it are straight out of Uncle Bob Martin’s bible “Clean Code” which if you haven’t read, you need to stop reading this article right now! There’s no time to waste here you’ve got a book to buy and reading to do!
Bob suggests that you should always be terrified about letting your code get poisoned by third party dependencies. He thinks that you should never surrender yourself to the whims of a third party developer. Don’t let someone else break your code, always put third party dependencies behind abstractions to avoid become a slave to these dependencies; is basically the essence of this argument.
In my own development I implement a flavour of this sentiment. Whilst there are a great number of dependencies that I do hide behind abstractions, like hiding ORMs behind the Repository pattern for example, there are an equal a number of dependencies that I simply accept as a dependencies that I’m going to have to live or die by, e.g. React or Dependency Injection Frameworks.
In a world where packages like left-pad can exist I think that we can all afford to be a little more prudent about the dependencies that we take in our software. The fact is that the ever present danger of repo abandonment, someone pulling their package of npm or just plain old breaking changes is very real and so much more pronounced when you can bring in 10 new dependencies in a single command line statement.
The abundance of packages and the breadth of functionality they can provide means if you get too dependency happy then it’s very easy to find yourself in a situation where you might find yourself surveying your laundry list of a package.json file and thinking to yourself a horrible, horrible question, “I wonder if I still use X package”.
The sad state of affairs is, you probably don’t, but are you going to go scour your code to find out? Nope. So you’re package.json will inevitably bloat and bloat until, eventually, you’re brave enough to try and do a clean out and I don’t need to tell you how that goes now do I?
Look, I don’t intend this to be another sensationalist “You might not need jQuery (or insert other insanely useful tool here)” type posts. But the fact is, most often, you might not. Might.
I’m not saying that should never take a dependency and that you should reinvent every wheel you come across. I’m just saying that you should be using dependencies to release pressure on your workflow which should allow you to reinvest that productivity back into your project. What you shouldn’t do is introduce Redux into your Clock app because your mate Dave told you how cool it was!
To give you a rock solid example: I have had a number of people contact me on the comments of my app building videos on the reactionary youtube channel. I want to say these comments are very helpful and welcome. So before I continue I’ll say explicitly, I’m certainly not trying to be negative towards the people making these comments.
Anyway, what they asked was if I was aware of a package called react-bootstrap that I could’ve used instead of manually using the css classes to create the bootstrap based UIs that I made in those videos. My answer to this question is always the same; yes, I’m aware or react-bootstrap but I didn’t use it in this application because the scope of the application didn’t call for it.
In my opinion little applications like the ones I build in my App building series don’t need to be making those sorts of gambles on dependencies. React-bootstrap, in this instance, just doesn’t cut enough complexity to justify the risk. What risk? The risk that taking that dependency might come back to burn me in the future. A dependency you don’t take can break your software right?
Where’s the advice?!
Let’s try to put a bow on everything I’m saying here. A decent analogy for how to draw dependencies into your project is to treat building your app like you’re building a high performance vehicle.
Hear me out, if your code base was the stock car then sure it could go alright around the race track. But if you really want to light up the track you’ll have to add on some third party high performance parts and systems, which in the apps case means take dependencies.
Sure you’ll add some parts but you aren’t about to add every high performance part that some bloke on the internet cobbled together in his garage! And one of the latest SpaceX rocket engines is probably going to do more harm than good.
You see some dependencies are definitely a good thing. But too much of a good thing ain’t a good thing, eventually you’re either just going to degrade performance or maintainability or extensibility or all three!
So in a line here’s the advice:
An ideal list of past lovers and and ideal list of dependencies have the same criteria: a short list of high quality.
More to come
Well, I hope I was able to make all the resonant with you. It would be great to see less developers hopeless chained by unruly and overgrown dependency chains and if we all adopt the mindset above then I think this utopia could be in our future.