You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apps are made of features. Typically these features are part of the same module or target where the whole application is defined - monolithic architecture. The natural inclination of the team is to continue building features. As a result, the application grows in complexity which manifests in bugs, bad compilation times, and team performance. What seemed to be good architecture didn't work out well in large codebases or teams.
The µFeatures main motivation is to support a scalable application. Features, helpers, and extensions can be separated into multiple modules and are called via protocols. With this implementation, the build system won't have to build the whole project due to small changes in the implementation files, thus, reducing the build time. Secondly, features come with an example in each module so the developer can quickly test their implementation.
µFeatures missions:
Building an app with independent modules (features).
Support the scalability of a large codebase.
To build, test and try the feature fast without the main app.
Reduce the build time if well constructed.
Also, applying µFeatures in the project will open a new door to build tools like Bazel or Buck, drastically reducing the build time.
Benefits:
Clear and concise
Working on smaller module
Reusability
Solution
This POC is a working template of µFeatures template; what we need to do will be:
Creating a script allows the developer to choose between monolithic architecture or µFeatures when initiating the project.
Refactor the code of POC to match our project structure and adapt it to our template. (Most of the crucial codes locate in Module.swift and Project+Templates.swift).
Who Benefits
iOS chapter
What Next?
Figure out what is missing and what we will need for µFeatures.
Discuss with iOS chapter members and finalize the approach.
Create stories for the Codemagic Epic.
Implement and create pull requests. 🙌
The text was updated successfully, but these errors were encountered:
@phongvhd93 I am really interested in these uFeatures , so I plan to convert my IC to use this to have a real feeling about it.
Will get back to you with feedback soon 👍
Issue
Apps are made of features. Typically these features are part of the same module or target where the whole application is defined - monolithic architecture. The natural inclination of the team is to continue building features. As a result, the application grows in complexity which manifests in bugs, bad compilation times, and team performance. What seemed to be good architecture didn't work out well in large codebases or teams.
The
µFeatures
main motivation is to support a scalable application. Features, helpers, and extensions can be separated into multiple modules and are called viaprotocols
. With this implementation, the build system won't have to build the whole project due to small changes in the implementation files, thus, reducing the build time. Secondly, features come with an example in each module so the developer can quickly test their implementation.µFeatures
missions:Also, applying
µFeatures
in the project will open a new door to build tools likeBazel
orBuck
, drastically reducing the build time.Benefits:
Solution
This POC is a working template of
µFeatures
template; what we need to do will be:monolithic architecture
orµFeatures
when initiating the project.POC
to match our project structure and adapt it to our template. (Most of the crucial codes locate inModule.swift
andProject+Templates.swift
).Who Benefits
iOS chapter
What Next?
µFeatures
.The text was updated successfully, but these errors were encountered: