Lessons From the Banjo Exercise

So we're all done with the banjo exercise, and I heard from a number of you that you really enjoyed it. I want to go today in a little more detail how what we did is applicable to the domain of web development, in which most of you are working.

Lessons to take from this exercise

I will once again remind you that this exercise was quite contrived, and so what we ended up with was extremely over-engineered for its scale. Even so, here are some of the lessons that I hope you took from it.

Learn to draw conceptual boundaries around the entities in your application

By distinguishing between the banjo itself and the banjo strings, we were able to address nuanced edge cases that would have been more difficult if the banjo was just producing a tone based on string number and fret number. The shortened fifth string, one note at a time per string, and handling broken strings all would have been significantly harder to keep track of and reliably build without some notion of a banjo string instance.

Keep your UI thin

Ideally, the UI should only be about presenting information to and collecting input from your users. Action handlers should delegate work of any complexity to modules that are responsible for that work specifically.

You know this pattern. It's the purpose of using Redux or any other state management library with React. React renders the page and its event handlers pass relevant information from those events to whatever you're using for state.

On the server side, the same is true for controllers and models. Your controllers are responsible for receiving an HTTP request and delegating that information to the appropriate model methods, then returning the result.

In our application, the ui.js file served as our UI, and the banjo.js file served as our data store.

I didn't write automated tests for this project (shame on me!) but a lesson that I want you to understand anyway is that UI is slow and brittle to test. The more you can keep your business logic independent of your UI, the easier it is to test.

Keep functions small and focused

Long, meandering functions are difficult to make sense of and debug. Don't be afraid to break functions down into smaller functions. It makes your code more readable, and it's easier to test and debug small functions.

The web is an event driven domain

User interactions, incoming server requests, task queues, they're all event-driven. As modern cloud architecture progresses, web development is only going to get more so. Get used to working with event-driven architecture. It's a very useful tool to have for decoupling components of your applications.

And with that we'll call the banjo exercise done. Tomorrow I'll start a week of content (maybe more) on Test Driven Development leading up to my webinar on the topic next Wednesday.

Next Up:
Why do we write tests?

Previously:
Wrapping up: Adding Sound to our Banjo