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.