How a Team Should Keep Up with Shifting De Facto Standards
summary
Defines when a team should follow shifting de facto standards and presents a concrete migration path used at Oisix: re-model domain boundaries, extract domain/infrastructure/use‑case into separate modules, and keep the UI stable while performing iterative domain‑first modularization. Recommends delaying MVVM and Jetpack Compose until after modularization, warns against blind migrations (Room vs file prefs, RxJava→Coroutines tradeoffs), and suggests starting with low‑risk modules using Google Codelabs and Dagger Hilt to reduce coupling and enable later Compose adoption.
AI-written summary · about
chapters (8)
- 0:00Tracking standards
- 3:58Identifying standards
- 7:44Why follow standards
- 10:11When to avoid standards
- 12:41Choosing standards
- 16:37Adoption timing and cost
- 18:49Refactoring to standards
- 24:06Conclusion
related talks
26mMigrating an app with millions of users progressively
36mCoupling Compose- Interoperability in a Legacy Codebase
37mAdopting Jetpack Compose Safely
45mMigrating a large-scale banking app to Compose
01h 09mJetpack Compose for consistency of your apps' UI
22mCompose Migration Side Effects - What Can Go Wrong?
25mWhat can we learn from Jetpack Compose?
31mArchitecture metamorphosis: a real case study