Ask HN: Do you reuse components from your previous projects?
What methods or tools do you use to reuse components/parts of your previous projects? Do you reuse components in most of your projects or just in some specific area like web development?
I have a junior developer who is hellbent on extracting little chunks of things to be “reused” on future projects but we work at a marketing agency that does a lot of bespoke design.
Sure, sites might have a collapsible FAQ section, but when the design is so wildly different from project to project, it takes more time to overwrite things than to start from scratch and write the 3 lines of jquery to get the section to toggle open and close.
I totally understand component driven UIs but marketing outside of generic landing pages is not a productive area to spend your time creating abstractions.
Nowadays I still copy code sometimes or re-use binaries if the builds are reproducible and I can safely streamline them but I don't try to properly extract anything anymore.
I use it on daily basis for storing my code snippets.
After making several npm packages, I've learnt that you need to put yourself in another frame of mind to reuse code. Here's some concrete steps in order to create good reusable components.
0. Ask yourself if this is this worth the overhead of code reuse???
1. Think from the perspective of the user of the component (because you will be the user in most cases), what's the most logical way to use and customise this thing?
2. Simplify the getting started as much as possible, it's much harder to reuse if it's complex to add to a project.
3. Remove as many dependencies as possible, this makes it simpler, lighter weight and allows more options for users of the package, (they can use different versions etc..).
4. Try to make an MVP and iterate on it.
5. Strive for backwards compatibility where ever possible.
There's probably many more good points I'm missing, but that's a few that I think are important.
I work in embedded so we reuse: device drivers, MCU abstraction layers, communication protocols, key (to our business) areas of application level logic.
Reusing components is about reusing design, which ultimately means you're reusing/extending a specification as well. If up front you can define the specification to be standard for a bunch of projects you can plan for a lot of reuse and justify the upfront work.
I keep them in private github repos and gists, i won't probably ever publish them since its a different "quality-standard" for documentation and code quality than doing something for myself.
I've lost count how many times I've implemented Google Tag Manager or Google's product feed on the ecommerce sites I build and maintain. Sometimes its a standard install (I should get around to building a collection of libraries for stuff like this). Othertimes it's a totally customized bespoke setup that tracks things down to individual clicks on every page (a good flag that the client is on its last legs).
Similarly, for those sites, I have a collection of Python scripts that translate between CSV and the standardized XML imports that the ecommerce platform uses (SFCC). I almost certainly have to modify it a bit for different heading names, but it works pretty well.
When I use Java and need to search through XML, I built a class that searches for a specified child element, because the NodeList class isn't iterable (can't be used in a for each).
I find that liberal use of copy-paste _across projects_ is way cheaper than building up a library of well thought out, generic components even in the long term.
If you have ten concurrent projects that need the same components at the same time it could make sense to build them up as privately published libraries. Otherwise it's unlikely that the overhead and rigidity of that approach will pay off if you only have one or two projects that you're actively working on at any given time.
Emphasis on "try": Some languages make it difficult to avoid code duplication in certain situations. (Looking at you, Go...) I allow code duplication if it's more readable than trying as hard as possible to refactor out common parts.
For Go-based API-driven services, we have collected some of these reusable modules and functions at https://github.com/sapcc/go-bits.
Also, this seriously breaks down when multiple developers are working in the same area.
To the extent that I do any work in other languages (Javascript, etc.) I do less of this because I'm less familiar with the tooling that is analogous to Maven/Artifactory.
On the downside, it's impossible to maintain it without automation. If I want to change something in several copies, I have to write a script to do this for me.
Web devs like to release generic reusable parts as open source. Often in the hope that someone else will help maintain them.
Whereas finance and game development like to keep custom tools and libraries that may give them an advantage in house.
I follow a rule of 3, if I have to do something at least 3 times, I refactor the code into a reusable component.
I would make use of a tool where I could "store" such components.
Another problem is that usually, I realize I want to change the basic component while I'm using it in a different project. So now I have to open another workspace, update it, and publish. Then `npm update` in the project where I'm using my component... I just feel it should be much easier.