The less code that touches my code, the better

When developing software, always look for potential APIs. An API is an Application Programming Interface (API). That is, the interface software uses to communicate with other software. On a basic level, you’re breaking a larger problem into smaller ones.

APIs have some pretty HUGE advantages.

– Easier to test (automated). Example: When you are adding after manufacture features, you have to rely on tests to give you confidence that you are not breaking something. Right, pretty common. But, when tests are all testing separate parts, it is much easier to find where and what went wrong. Also, take for example a large web application like butterapp (I will use this as an example again). How does one test an application built around visual, UI, and interactivity with automated tests? Simulate a bunch of clicks, and compare the pixels? Or, start at the other end, the first thing that happens when that click happens, and work your way up to the actual click. Think a large engine, you can test the engine. Or, you break it into smaller engines, that sends commands to the larger engine. The smaller piece knows everything it is capable of doing, so you test everything it can do. You’re not testing end results, but functionality of the pieces. You’ll also come out with much stronger tests as a whole. That being said, no harm in visual tests of the end result as well. You can never have too many tests.

– Easier to maintain. Once you know where something is broken because a failed test led you to the broken area, you can lift it out, re wire its internals, and put it back in and none of the other parts know anything has changed, because the interface is the same. Adding new features become much easier, because an API is designed from an abstract point of view. You can easily change the way the parts interfaces with the other parts, to get different results. It is easier to read, like a book, to a point. A badly designed API is just spaghetti code. A good way to avoid this is to keep in mind that the less code that touches your code, the better. Modular, dynamic, and living in its own scope. We don’t share our Tupperware with our neighbors here.

– Distributable. Never know, someone else may have a need for the pieces in your engine, to use in something completely different. This also opens up my last point.

– Collaborative. Once people start using it for other things, to solve other problems, your community will grow exponentially.

What made me ramble about all this?

I’ve been working on something called butterapp, which is the front end registration tool for popcorn.js. Inside Butter, is a visual track, containing events attached to a timeline. So me and Bobby Richter specced out trackLiner.js. Here is an older demo I did to show while it was in mid development. And, here it is, updated, and plugged into butter.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: