Often when beginning a new project, I start out with what I believe to be the best of intentions in terms of how to structure the codebase. I love the idea of numerous small modules that do one thing well, are de-coupled from other parts of the codebase, and could potentially be reused by myself in other (similar) projects or open sourced for others to take advantage of.
However, come crunch week when I’m actually trying to get something into production, there’s been more than one occasion where the complexity of managing all these different modules has proved too much of an overhead (despite good documentation and deploy methodology). On those times I’ve simply changed tack and bundled all the modules into one repository and managed it all as one codebase, meaning I can track everything together through different branches, deploying to staging and test environments, etc…
What are the advantages and disadvantages of these different approaches, and how do you manage working in one way or the other?
Advantages of one monolithic codebase:
- Easy to deploy
- Easy to rollback
- Easy to branch/manage all changes together
- No (or less) potentially complex dependencies to document and manage
Advantages of modular dependencies:
- Reusability
- Clean architecture (one module does one thing well)
I do not see the opposites as much as you do. Taking a .NET experience as an example, I can ensure parts of my code are geared towards well-defined responsibilities, I can structure my codebase into namespaces, ensuring that the touching points of the namespaces are well defined and that classes within the same namespace really do belong together.
However, all this can happen within a single unit of deployment, single project, branch, what have you. If you stick to that, units of code that may become reusable in the context of the projects you do will crystallize and that would be the point where you may decide to introduce a new unit of code, with its own deployment artefact, source control branch, etc.