Lately I’ve been refactoring lots of code (both mine and others’), much of it Javascript. These areas of the code make up core features of the application. But I found myself writing them like stand-alone projects with hooks for the larger application. They may not be useful stand-alone projects, but I’ve found the mindset very helpful during development.
I am by no means suggesting that this mindset is anything new and extraordinary. But for whatever it’s worth, I’ve decided to outline my rational here.
Easier for yourself and others to read/maintain
By isolating specific features as self-contained libraries, another developer (or yourself in six months) will have a much easier time grasping 1) what they do, and 2) how everything interacts.
This is similar to some of the rational behind object-oriented programming. I guess there’s some overlap, but this goes beyond encapsulating behavior inside of objects. It encourages you to think of your application code as a collection of discrete feature components. Feature-oriented design?
May help you find an existing library
By mentally breaking down new functionality into discrete features, you may discover an existing library that covers one of them. Yay!
You could release it, become wildly popular, and ride your success on to fame and fortune
More realistically, three other people will use it, say “thanks”, and you will pat yourself on the back. But that still feels nice.
Concrete example
One of my personal projects has a feature similar to Google’s chat windows in Gmail. While adding support for EventSource I refactored the whole of it. When I finished, a library had emerged for controlling pop-up chat window UI and message events. Boom.
Will I release it? I don’t know; it would need a little more work to be truly useful outside my app. But it’s so much nicer to work with now.
This road may lead to madness
Obviously this can be taken too far. At a previous employer I was part of a team writing an internal-only application. Early on there was some high-level discussion that it could be useful to others, and that we may open-source it. As time went on we realized that open-sourcing the code was increasingly unlikely, for a variety of reasons. Nevertheless we strove to make the application business-rule agnostic and configurable to a fault. In my opinion, the result was a product that could have been better for our users.
So don’t do that. Don’t think, “I’ll write this so that anyone could use it anywhere!” Instead think, “If I found this feature this on Github, how would I want it to integrate with my app?” You may still end up with a library to release. But if not, it’s okay; you’ve still written better code for your app.
Discalimer
Some bearded guru who’s 10x the programmer I will ever be has probably written something like this, or something decrying it, 100x more eloquently, in a widely-read tome which I have missed. Please tell me, because I’d love to read it.