In Javascript app development maintainability is often exchanged for rapid production and delivery. Using Javascript code modules is not a new concept to software developers who write single-page JS apps but the distinction between using namespaces with a singleton-style static object and writing modules is important.
I keep hearing that modules improve executing speed and reduce memory footprint but none of that matters right now. I was once told by a senior developer that “Shipping is the most important feature.” For web developers that is most often the case. We don’t have time to test and retest algorithms for performance in rapid production cycles. What little time for testing has been budgeted is best used on following a critical path of functionality from the user’s perspective. Fixing bugs in those critical features takes precious time away from finishing and delivering the product. Working in readable, maintainable code keeps developers in control and stakeholders satisfied.
In Mikito (mixu) Takada’s free book Single page apps in depth he describes modular code design:
Modular code is code which is separated into independent modules. The idea is that internal details of individual modules should be hidden behind a public interface, making each module easier to understand, test and refactor independently of others.
Modularity is not just about code organization. You can have code that looks modular, but isn’t. You can arrange your code in multiple modules and have namespaces, but that code can still expose its private details and have complex interdependencies through expectations about other parts of the code.
In college we called this methodology “design by contract” and at a code implementation level it describes a set of methods and objects that do only what they are expected to do and have clearly defined inputs and outputs. This pattern also strongly discourages side-effects.
The contract is not necessarily between user and application but between objects and functions within the system. Design by contract has a much bigger implication on maintainable code when external APIs are involved.
Javascript is not just a hobbyist’s scripting language from the 90’s. Okay, yes it is a hobbyist’s scripting language from the 90’s but not to me! Complex applications with mission-critical schedules depend on Javascript. Approaching software design problems from maintainability perspective will continue to elevate Javascript and web developers’ status in the software engineering field. Let’s get serious about Javascript!
Aaron Bronow 