Developers had to follow a complex integration process for each component they borrowed, and maintaining them was a hassle.
That’s where packages and package managers came into play. A package is a reusable piece of software that serves as a shortcut to a specific task. Rather than recreating the component from scratch, developers can simply download the package and copy it into their project.
The package might or might not have dependencies required for it to work. Dependencies are complex to manage.
Sometimes when a package is updated some dependencies are no longer compatible and require the old version, creating a situation known to developers as “dependency hell”. This can’t be avoided by skipping updates, though; packages have to be updated to maintain performance and close security vulnerabilities.
The solution to this problem is package managers: tools that automate and simplify the use of packages. They automatically handle dependencies, configuring updates, installing new packages, and other tedious yet essential tasks. Package managers are what makes using so many different components possible, reducing the overall time spent on maintenance and installation.
Another reusable code trend gaining traction is the idea of a “starter kit”. This is a developer or organization-specific foundation for building apps that has all the basic opinions and configurations built in.
When beginning a new project, the team uses the starter kit as a jumping-off point. They don’t have to worry about skipping a step that might cause trouble down the road because the foundation work is already done.
This approach has several advantages. It eliminates the time spent on less productive discussions like arguments about syntax. Instead, the team jumps straight into the project at hand. Starter kits also streamline the quality control process by ensures the entire team is working to the same settings.
Why Not Start From Scratch?
Time spent recreating components which have been built many times before is time that isn’t spent trying new things. It doesn’t push technology forward. Developers need to build on the community’s work if they want to reach higher levels of sophistication and create something new.
Going Full-Stack with Reusable Code
Back-end developers have access to more tools for building out the front end. The team can work together to create a better experience for end users (which should be one of the primary goals of any software development project).
- Reduced server load
- Faster response and page load times
- Wide compatibility across devices and platforms
- Easy maintenance and debugging
- Offline access
- Faster development and updating
- Lower maintenance costs
Committing to Reusable Components
In this day and age most developers are probably already using reusable components to some extent. However, the majority haven’t fully committed to applying reusable code wherever it’s relevant. They’re missing opportunities to improve their products and provide faster development to their clients.
Package managers are the form of reusable code mostly likely to be used by developers at the moment. The increasingly popular Node Package Manager (NPM) is the fastest growing, though others like Bower, jspm, and Duo have their uses as well.
Sharing code like this meets resistance from a lot of executives who worry about giving away trade secrets. In practice, that isn’t a serious concern. Sharing components isn’t the same as putting completed software online for free; it won’t let competitors steal a product under development and release it early.
Beyond that altruistic motive, sharing code builds a company’s reputation as an industry leader. Peers who use the components gain respect for the developer, which makes hiring and retention easier.
Reviews serve to validate the company’s expertise for potential clients. There’s also the possibility of spurring a new trend in programming that could inspire industry press attention, which leads to more and better clients.
Team members need to buy into the concept, and the best way to ensure that is to give them the sense of ownership collaboration provides.
These kits should lay out standards for start-of-project decisions, touching on topics like editors, bundlers, testing frameworks, preferred HTML versions, logging protocols, API structure, and anything else that makes sense for the company.
Aim for a “highest common ground” where many set-up decisions are premade but the team isn’t prevented from creative problem-solving.
Developers have nothing to lose by sharing their expertise- and everything to gain.