Taming Complexity with the Module Pattern
It's often said that it's easier to write code than to read code, leading to a bias towards developing new code rather than updating existing codebases. I often fall for this myself - it's fun to learn newer technologies and apply cutting-edge techniques to solve problems. Sometimes this can work to your advantage: companies may leapfrog others, allowing them to catch up or even surpass competitors purely through innovation. Newer frameworks can eliminate whole classes of problems, allowing you to focus more intently on the problem domain.
But sometimes the cost of implementing a new solution is greater than the benefits of the new solution. Sometimes there is a cost that comes with disrupting something that is already solving a problem, even if it's a nightmare to work with.
Recently, I was fixing bugs in an outdated VB MVC app with older versions of jQuery on the frontend. This is an application created by someone that is no longer at the company, that few people have touched, and one that is actively used by customers and internal employees alike. My horror grew with each file I reviewed:
- ~200 loc controller methods containing dozens of logical branches and loop-less assignments to objects & arrays
- Duplicated logic in both server-side .vbhtml files & jQuery ajax calls
- Global JS variables scattered throughout a dozen different files that get reset with each page load
- Last deployed 2 years ago, without any code history over 6 months
My stress kept rising as I tried to follow the flow of data from stored procedure, to VB method, to ajax calls, to the DOM methods for inserting this data. The frustrating part about tightly-coupled code is that you can't look at any part in isolation - you are required to keep this run-on sentence of logic in your head to make sense of the whole.
With this pattern, I was able to begin moving duplicated logic throughout the frontend of the app into a single place. This had the effect of making the code more predictable and organized, and much easier to deal with.
And another nice feature of the moduel pattern: the variables declared within the IIFE can only be mutated by the methods you expose, allowing you to manage internal state of the module in a controlled fashion. No more hunting around for some global variable declared in a random .vbhtml partial.