New Team, New App, New Architecture
As a new member joining the China Development Center, a new site in Shanghai helping transform digital business of Fast Retailing. I’m going to co-work with Japan mobile team to deliver next generation mobile experience for Uniqlo customers. And from the beginning, I’m serious about the architecture and tech stacks we’re going to use in our mobile application.
Based on the existing code base, the early members tried to adopt what’s called the Clean Architecture, which is built upon the traditional MVVM model but goes even further. The entire functionalities are defined through a variety of protocols and corresponding implementations. Then they use dependencies injections as a way of initializing and providing services, which are generally separated into stuff like
DataManager, etc. And the communications between different parts are through
RxJava on Android) binding and callback handling.
There’s no single, best architecture
I don’t think there’s a good architecture that can be applied to all the projects. My previous adoption of MVVM architecture is a result of carefully measuring our technology target as well as the flexibilities we might need in the future. The
ViewController is a simple and lightweight structure and each part serves particular needs.
DataManager are the abstraction layer of the backend services and designed to be shared throughout the application or even different mobile products.
ViewModel is isolated because we want to build a user interface that’s unit test friendly. A widely accepted opinion is that greater test coverage leads to better app qualities.
ViewController handles the heavy duty content display including all the view management, animations, etc.
All the parts are designed for different purpose like great reusability, testability, and flexibility, that everyone in the team has a good idea of.
Learning Curve, On-boarding Issues
The introduction of
Swinject definitely creates a learning curve for any new joiner. And having a good knowledge of 3rd party frameworks relied on are becoming the requirements for those who are going to work on a new feature or even fix bugs.
More importantly, the entire application is built heavily on RxSwift and other frameworks, which is definitely kind of risk for future maintenance. And also the adoptions of new technologies and new development tools must ensure the compatibilities with 3rd party libraries. As a result, I don’t think it’s a great solution for creating a future-proof technology stacks.
For a member in the development team, once he can understand the philosophy of architecture behind, the key part for the on-boarding period is providing a step-by-step tutorial so that one can get his hands on code base as soon as possible. This part is missing at this point, but I’m working on it.
Pros and Cons, Decision Making, Driving Consensus
In terms of building architecture, different people make different choices. But it’s important to appreciate we carefully measure the pros and cons for any decision made. Those reasons will guide you in case you are lost and also tell you why you failed.
No matter who makes the final decision or which architecture is adopted. As long as those decisions make sense and architectures bring clear benefits, everyone can understand and be ok with it.
The clear process of decision making helps drive consensus in team. Making sure everyone is on the same page of where are we going will provide great confidence to the team down the road.
Great Flexibility, Feature First
We choose architecture carefully because we want it to be sustainable and can support our product/business in the future we can imagine.
But for a new project built from the ground up, it’s often hard to predict the what a product would look like or what does the market really need. So it’s important to have great flexibility in the architecture which also should be lightweight as well. It’s meaningless to have a great architecture if the product is dead on arrival.