In our work, we come across a plenty of libraries, frameworks, and tools. Among the alternatives, we are supposed to choose the best option—and support the existing code relying on it.
So how do we navigate the endless sea of “yet another” frameworks and distinguish the useful tools from garbage? How do we measure the frameworks’ trustworthiness and their current state of development?
In the world of Ruby development, choosing between different open source tools has become a part of a routine project development lifespan. It has become quite a challenge to use many dependencies in a project since the creation of RubyGems and Bundler.
It does not occur to us, however, that our apps and libraries’ code is now mostly not the actual code we write, but a code of third-party libraries we are not even familiar with.
Like Uncle Ben taught us, “With great power comes great responsibility”. The least, unfortunately, is slowly vanishing in a sea of plug and play open source solutions for virtually any task.
Often we’d not even scan the code we want to use: we will just plug a new library in and see what happens. With this approach, there’s high risk we end up using the wrong tool—think using a hammer instead of a screwdriver.
The team at Thoughtbot has put together this checklist for trying new libraries:
- Evaluate the maintenance quality;
- Check the quality and security of the code;