iOS Teck Lead. I work at TRIARE.net
In part 1, we reviewed the work with modular architecture in depth. In this article, I want to finalize our findings.
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.
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.
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.
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:
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/
Create your free account to unlock your custom reading experience.