Fighting Code Chaos with the Right Framework

From the outset we knew that the dashboard—the web application our audience engagement team will use to answer incoming questions—was going to be a huge undertaking and we knew we had to lay solid foundation for app development. Since we were doing agile development and designing the app based on user testing, the feature list of the dashboard would likely not be set in stone.

For the dashboard, we had to develop it in a timely manner and still be able to make changes to the codebase without breaking it (think Jenga). Also, we wanted the app to be easy to maintain over time, since it would be a web app that we would be using for years. The best case scenario is an app that was coded in such a way that it is quick to build, is easy to maintain and is easy to adapt to any unforeseen needs. The worse case scenario is unruly legacy code—codebase that degrades over time—and spaghetti code—a disorganized code base.

Legacy code degrades because people forget how to use the code. This could be due to the lack of documentation about the code base or obtuse application architecture. With spaghetti code, it becomes more of a chore to find the causes of bugs and implementing a new feature becomes more involved and troublesome, since introducing a new part into a disorganized system might cause problems with existing parts of that system. Spaghetti code inevitably leads to legacy code.

There are a few ways to mitigate legacy and spaghetti code. There could be a dedicated effort to write good code documentation and to establish a logical app architecture. We pledged to ourselves to do those things, but also thought it be a good (and a smart idea) to use a framework (in the case of the dashboard, a Javascript framework). Coding frameworks provide guidelines and conventions for how code is structured and organized.

Using a framework is an easier way for a team to provide organization to their codebase. In addition to a kind of application blueprint, some frameworks also provide abstractions and functions for common development tasks (ie. communicating with an API, implementing animations, data modeling, rendering data to the user). Developers will not have to start from scratch and write their own, idiosyncratic functions for common tasks. Instead, team members would be using the same library of methods and variables. Some frameworks (especially free, open-source ones) also have large communities of developers supporting each other in using that framework. Using a framework, would allow us to draw upon that community as a resource.

It seems like every day there is a new JavaScript framework popping up, but I focused our search to two frameworks: Backbone.js and Angular.js. I chose to look at those two because both frameworks are being used in live web apps by large web companies. Both have good documentation (which makes the framework easy to learn) and large communities.

The way I judged Backbone and Angular was by building a quick and dirty prototype in each. I chose to build a feature that we knew would be in the final version of the dashboard app: a chat window. This chat window allows the user of dashboard to choose a visitor who is waiting in a queue. Then the user of the dashboard can continue the conversation with the visitor. After building the same feature in both frameworks, we decided that Angular was best suited to our needs.

Angular has been criticized for being “highly opinionated,” which means that the framework has a strict application blueprint. For us, Angular having opinions and conventions for application structure meant that we can build something really quickly because we did not have to spend too much time in the planning stages. Angular’s guidelines for building a web app were strict, but not too rigid. Angular strongly encourages developers to write modular code, which means pieces of code can be re-usuable and dropped in when its needed. Every kind of function and variable has its place, which helps with fighting spaghetti code.

Angular also includes a large library of functions for a lot of tasks that we hope to accomplish with the Dashboard app. Tasks like animating user interface elements and interacting with our custom API. With Backbone, we would have had to write a decent amount of boilerplate code (that will likely become legacy code). With Angular, developers won’t have to spend time re-inventing the wheel and they won’t have to spend time re-learning how and why their team mates wrote a certain function.

In addition, unit and integration testing are core features in Angular. Unit and integration testing ensures that any feature implemented in the future does not break existing features. Tests are actually bits of code that makes sure other bits of code are working properly. Angular makes writing tests easier, which makes it more likely for developers to write them (thus preventing legacy code). Tests can also serve as documentation on how the code base works.

Using a framework does not guarantee completely against legacy and spaghetti code, but they can provide a strong foundation for building large apps, like our dashboard.