Modularity is important, there's no doubt about it. Modular code allows for separation of concerns, code reusability, easier maintenance, easier collaboration, easier testing and debugging, and the list goes on and on.
Frontend components, microservices, functional programming, micro-frontends, etc. - these are all manifestations of that crucial concept. They exist because the idea of modularity is acknowledged and embraced by the community.
On the other hand, we see symptoms of monolithic code everywhere. Modifying code is a terrifying thing - you change one thing and the whole thing collapse (remember "Stackers"?). Incorporating new members in a dev team is a difficult enterprise. Collaborating on individual pieces of code (in isolation) is extremely difficult. We spend too much time on either building things from scratch or packaging code for re-use.
So, what's really going on?
Our current version control systems are simply not fit for a truly modular code. We can write our code as modular as we possibly can but it will all be in the same monolithic repository (and not so modular). We may choose to turn to multiple repositories in an aim to make our code truly modular but we know the nightmare that awaits us if we so choose.
There are several attempts to solve the problem of monolithic repositories (Lerna, git submodules, etc.) but, IMHO, they are still far from what should be an easy, intuitive and seamless workflow of building, collaborating and consuming multiple components or modules in multiple projects (each of these projects may have its own single repository but it should only represent a particular combination of truly independent modules).
There are other new platforms and tools that aim to solve that problem (Bit.dev, etc.) - time will tell if they manage to give a more complete solution.
Top comments (0)