When embarking on a greenfield project, the initial development phase often feels like a breeze. Features are fresh, and there’s no need to grapple with someone else's code. Everything flows smoothly, and the codebase evolves organically. However, as the project matures and new developers join, the code can become tangled, making it harder to understand, modify, or extend.
Enforcing Separation of Concerns
Enforcing separation of concerns by splitting the code into modules ensures that each module has a clear responsibility, making the overall structure more manageable and paving the way for future scalability. When an application is modularized, you must explicitly import other modules to use their classes and functions. This necessity compels developers to be mindful about what should be exposed publicly and what should remain private, fostering a more disciplined and efficient development process.
Mindful Development Practices
While setting up modules and defining public access modifiers may seem to slow down development in the short term, it's important to remember the long-term benefits. This discipline pays off as the application grows, preventing the code from becoming overly entangled and making future development faster and more efficient. Each module only builds its dependencies, not the entire codebase, reducing build times. This benefit is further enhanced with the introduction of explicitly built modules, which allow for parallel builds, giving developers more confidence in the scalability and efficiency of their work.
Initial Time Investment
Modularization does take some extra time at the beginning. However, this upfront investment saves much time in the long run, as the code will be more manageable. Retrofitting modularization into an existing codebase is very challenging, so it’s much better to implement it from the start.
Approaches to Modularization
There are a few approaches when approaching modularization:
Workspace with multiple projects (usually paired with Tuist) - Apple Documentation - Managing Multiple Projects and Their Dependencies
Project with multiple packages - Apple Documentation - Organizing Your Code with Local Packages
Project with one package that describes all the submodules - Point Free - Modularization
Here is a template project that utilized the third approach. The package file describes all the modules which can be imported and used in other parts of the code.
Managing Access Levels with Packages
Accessing classes, properties, or methods in another package requires them to be explicitly public.
By default, these elements are private, ensuring encapsulation.
To access classes, properties, or methods within the same package but across different targets, such as for testing purposes, use the internal access level.
Conclusion
Modularization might introduce some upfront complexity but fosters a cleaner, more maintainable codebase in the long run. The benefits are Separation of Concerns, Quicker Builds, and Quicker Development in the Long Term.
These benefits become increasingly apparent as projects scale, leading to more efficient and sustainable software development practices.
Couple of Visual Resources
Package.swift file describing different submodules and targets:
Corresponding targets:
Comments