The development phase is often the longest and most expensive part of producing a mobile application. This phase often involves shared inputs by several developers over long periods. If one does not pay attention, this joint effort might fail. This failure often lead to disorganized code that becomes increasingly difficult to maintain. In a sort of snowball effect, it delays the project while adding further costs.
We are convinced that to get around this problem, one has to ensure that the project is based on solid foundations. We must not charge blindly into the development of the project without having taken the time to think about the structure given to the code. This is the architecturing of the code. By ensuring that the team has the theoretical foundations and the practical knowledge that will allow to properly architecture the code, we can carry out this phase of realization without delays.
# 1: Problems coming from a badly architected code
Noticing a rising issue and preventing the damage is often difficult while developing a project. The main problem, which we will call viscosity, is often manifested by estimates that are lengthening over time, or when it becomes increasingly difficult to make changes or introduce new features in an existing codebase. There are multiple causes of viscosity; the major one comes from a strong coupling between its different components, such as classes, interfaces or modules. That is, there are too many dependencies between the different components and the responsibility for each component is not well established.
To overcome these problems of coupling and viscosity, we must put some thought into architecturing the code. As Martin Fowler mentioned in his article Design Stamina Hypothesis, a well-crafted code solves the problem of viscosity and keeps efficiency throughout development.
However, « good code design » is not limited to simply choosing an architecture. One must be careful to master the theoretical concepts in order to apply the chosen architecture in the right way. The development phase of a project is similar to building a house. To choose an architecture is to decide what plan to follow, and not to start building until a consensus is reached on what must be built and in what order. A plan cannot be carelessly drawn; the architect must rely on several theoretical rules that ensure that the house can stand up. The plan by itself is not very important as many similar plans can create look-a-like houses. On the other hand, a plan that does not meet the rules will always give an unstable house. This is why we focus on these underlying theoretical rules, regardless of the chosen architecture.
# 2: Theoretical principles that every developer must know
The developers among you will have already seen some « good practices », often in the form of recommendations such as « composition over inheritance ». These recommendations are in fact tips that most often allow to comply with the underlying theoretical principles without knowing it: the SOLID principles. The understanding and application of these principles reduces the coupling of the code and thus its viscosity. The example mentioned above, “composition over inheritance” is actually a trick for applying Liskov’s substitution principle, which explains the constraints that must be respected when using inheritance between classes. It is far more effective to know what the principle says than to blindly apply that trick.
Bob Martin, who introduced these concepts in his book Clean Code, proposed an architecture that helps implement these principles, called Clean Architecture.
# 3: Build a SOLID mobile application project
SOLID principles are the theoretical foundation needed to build a house that will keep on standing over time. Knowing them and knowing how to apply them, whether through the Clean Architecture or any other architecture, is essential if we want to ensure high chances of success during the development phase. The effect of their application is a decoupled code. Aside from the absence of viscosity, the decoupled code also has other advantages.
Adopting Clean Code is the guarantee, for a team working on a mobile application project:
- To be able to perform tests much more easily throughout the development. The decoupling of the code makes it possible to isolate components that otherwise can only be tested jointly.
- Again, by isolating components with Clean Code, the management of the project schedule is optimized. This segmentation decreases dependency on external elements, such as delays in delivery of design mock-ups or being slowed by external services.
- Increase the flexibility in managing the involved human resources: more developers can work more easily and in parallel on different functionalities.
Discover next week our article on the solutions we use to test our code.Receive our newsletter