Tuesday, May 29, 2012

JSGentleman Rule #4: write libraries

We all know that decoupling is a good thing and the best way to do that when writing an application is to write libraries instead of application code.

What you can do now is to take parts of code that you have written, minimize it's dependancies and then generalize the input. Viola - a library that can be used in future projects.

Whenever I start a new project I try and identify parts of the program that can be abstracted, give it an API and make sure I don't pull in dependancies from elsewhere in the program (unless necessary and explicitly stated). Working like this helps decouple the project and stating dependancies and an interface will help future developers working on your project, but there are also more benefits.

Writing as a library will allow you to easily open-source non-critical parts of your project which can help the community, promote your company, and get feedback to improve the code. It also means that other people will be looking at your code which means you'll stay a bit more alert about writing good clean code, documentation and testing.

When working on your new library you may also put in extra functionality that isn't necessary in your project. This is good practice as it can help you in future iterations. I find sometimes I like to work on a library separate of a project to add in new features, only to then realize I can actually use these new features in the product. It's a win-win, and if you're using a minified like Closure-Compiler you won't have to worry about bloat as it removes unused functions.

The final reason is that it's a good abstraction. You might start writing out parts of the program only to realize that someone else has done a better job and because you started with a decoupled design it shouldn't be too hard to swap out for another library.

So next time you start on a new part of your program think about how you can generalize it, then stick it up on github.

1 comment: