What We Learned from Working with Modules: Summary

In part 1, we reviewed the work with modular architecture in depth. In this article, I want to finalize our findings.

Key takeaways from Modular Architecture:

• The diversity of projects on MVC, MVVM and other legacy code peculiarities can leave you knackered, while modules offer clarity.
• The seams need to be sustained, and the best way is to separate logic.
• Modules contribute to a unified approach, well-coordinated teamwork, and delineated areas of responsibility.
• Modules help with iterations and adjusting to new requirements.
• The amount of extraneous code is reduced.
• There’s a ready-made foundation for each new project.
• The most important benefit of modules is independence.
• Of course, there are disadvantages, but they're easy to get used to.  

Why did we begin to use modules?

We have received many projects built on various architectures. So, every time, we’ve put a lot of effort to sort the code out. Projects have their peculiarities depending on the country they come from. For some reason, many have half of their legacy code in Objective C and the other half in Swift. In all the cases, clients want to introduce changes to the existing code, which is really hard to maintain.

The seams we were trying to save and sustain were cut all the time, so we had to create little pieces of code to glue it together. Thus, we were changing the architecture. It led us to the idea of taking those pieces out into separate files, to mark our areas of responsibility in case something went wrong.

These factors led us to modules, code standardization, and the habit of writing and reading code correctly. The seams were taken out in separate modules, and problems with functional tasks were solved in isolation.

That is when we started to realize the many benefits of modular design.

Let’s analyze the pros!

From time to time, developers make rotations between projects, which are built on different architectures. Areas of responsibility on monoliths are not explicit – while modules are clear cut. A unified approach also made onboarding newcomers easier. We use one style when writing a module, and learn to speak one language when writing the docs.

Worthy to note, that each module can have a different implementation approach – and this does not affect the overall structure. As long as it passes code review, and everyone’s satisfied. The only caveat being the necessity to arrange the correct access levels. There should only be one module “owner” to make decisions. Such a system teaches developers not to be lazy and decreases stress levels.

Modules help iterations. We create a scheme of modules and their splices at the very beginning of the project, before accumulating the code inside each module. Firstly, it prevents harm to the project in case there's a mistake inside one module. Secondly, iteration helps when developing large projects with fast vector changes. Modules are interchangeable, which means that we can adjust the business value at any time.

In addition, we have reduced the amount of extraneous code. Over time, after developing 10+ modules, we began to cover the functionality that usually comes from the libraries: onboarding, REST API, ImagePickers, ColorPickers, etc.

Each new project has a ready-made foundation, so we can switch between them quickly. Therefore, we decrease the time for estimation at the beginning.

What is the benefit of modular design?

If you asked me about one most important benefit – it's independence. When I need to introduce very quick changes to see the big picture, I can sketch something and come back later to polish it. That's common practice among developers. Even if the module is written badly on the inside, it will perform well on the outside due to the predetermined splices with other parts of the project.

What are the disadvantages of modular programming?

• When transitioning to modular programming, you will have to be patient and habituate yourself to describe the code and documentation.
• You need to cultivate a vision of dependencies, learn to define and divide functionality in modules.
• Also, it is necessary to keep modules up-to-date both in the main project and in the module repository.
• Since each module is a separate framework, you’ll have to define an integration path for SPM / CocoaPods / .framework.
• The developer on the team should not distract the module developer. A module is considered dead if there are no docs.

Our experience in modular programming

We have created six active modular applications and 10+ modules that continue to be intensively developed (in various independent projects). The benefits of a modular approach to app development have been clear:

• The speed of initialization of projects and development has been increasing due to the accumulation of ready-made code.
• Developers transmit knowledge via the description of the module code and documentation.
• A new navigation module has been built that covers the Router's needs and weaknesses (check how it looks in the previous article).
• Integration of tests, implementation of TDD have been simplified.
• Code always remains up-to-date due to module reuse. It saves days on updating projects that have been on a long stand-by.
• It’s easier for developers to switch between projects and tasks, the bus factor is reduced.

To sum up

When I first started learning about modules, everything seemed too complicated. Now I can tell you it’s not. I want my team to develop code – easily. No complicated architectures that take 5-6 hours to deploy. No projects with legacy code taking 8 hours daily to maintain.

A project must be simple for every team member as well as for external use. To me, that's the key to developing quality code and creating successful projects.

Also published on: https://triare.net/insights/modular-architecture-2/