Similarity to Travo

The closer we’re approaching the beta release, the more I feel the similarity of the current situation to that I had in my second company: Travo. Although the FastRetailing itself is by no means comparable to a startup, their mobile apps are both for EC and the development process almost shares the same pattern, which means design specs change all the time(usually several times per week) and Biz requirements are not clarified until days before the deadline.

Lego.framework

Most of the changes require UI modifications, since Biz people only care about what they can see and the functionalities are largely determined by backend capabilities, which require much greater effort to change.

From the engineers' perspective, we're building our own UIKit as I mentioned in the previous post because we have ideas in mind that the UIKit can reduce effort for future development if some components can be reusable or shared.

That’s exactly what I had in mind 5 years ago. And eventually that didn’t work at all because even a minor design difference could destroy the hope of making a reusable component. Most of the time, the those differences are designed on purpose and come from Biz requests, which we can hardly say no.

After I struggled for several weeks and later I found the solution, which still works pretty well even for today. That is, rather than create full-featured UI component with rich content, try to split the component into tiny pieces and then mix and match them to create a fully useful one.

Because each pieces are so simple and so tiny, there’s no chance they will be affected by each design change, and therefore increasing the possibilities of reuse. Even they do need to be changed sometime, the effort is minimal and the risks are greatly reduced.

ProductCollectionCell is a good example. It is obviously shared between multiple pages, but there are little differences on each page. It’s hard for us to create a consistent layout which works for each use-case. So we built components like StarIndicator PriceLabel and FavoriteButton which can be shared somewhere else, but keep the flexibility of layout which changes frequently.

Avoid abstraction in early stage

Another trap early developers can easily step into is that they try to extract reusable parts when those appear in more than one places.

Early abstraction turns out to be troublesome rather than helpful, because different use-cases always fight with each other by changing the shared resources for their own needs.

In terms of feature versus architecture, my experiences are that we should always build each feature independently without thinking too much about flexibility or reusability. Implement the functionalities first then optimize the architecture later, because more or less, each part is gonna to be changed a little bit before final release.

When extracting shared UI resources, make sure to leave some rooms for potential changes but only support flexibility to a limited extent. Greater abstraction can take place and do its job for the future when the overall features are stabilized after several releases.