Classes • Different code styles at the same base code • Base Classes (BaseActivity, BaseUseCase, BasePresenter, BaseViewModel, etc.) • LiveData or Android classes in all Layers • Expose MutableLiveData • ViewModels without CoroutineDispatcher or Scheduler as argument • Handle Errors (try / catch everywhere) • Wrong dependency injection implementations • Unreliable test or not tests • Technical Decisions Making
project • Modules organized around business functionality (checkout, users) • Cyclic feature modules • Hard to communication between feature modules • Hard to share resources or reuse code if shared modules approach is not used
project • Modules organized around layer functionality (data/domain/UI) • Possibility to keep purely kotlin module without android framework classes • Coupling Modules (strong dependencies) • Excessive abstraction usages, add complexity code navigation. • Exposed to create a bunch of git conflicts - Complicates collaboration • Build time performance can be affected • Hard to share resources or reuse code if shared modules approach is not used
multi-module android project • Modules organized around layer and feature functionality (mix) • Reuse code using shared modules as Core Module • Possibility to keep purely kotlin module without android framework classes • Centralized UI logic in app module • Slow compile time switching between variants • Reduce decoupling from libraries (not dagger in all modules)
project • Useful to reuse code on different projects at same company • Useful for large and distributed teams (10 devs or more) • Complicated navigation between libraries and projects on AS • Hard to upgrade, implies a new library release (automate) • Development time can be affected adding new functionality to the library • Hard to maintain multiple libraries / projects at the same time • Hard to maintain consistency in version across all modules
• Modules organized around features functionality (about, users, shopping) • Complicated to decide if use on demand module true/false • Limited compatibility with aab • Slow compile time switching between variants • Navigation • Premature Optimization
tools, libraries, programming languages with your team knows and feel comfortable, even better if your project get benefited • Prevent over-engineering, "Done is better than perfect" • Despite your values and disciplines and practices, the health of the organization will be an upper bound on the health of your code. • Communication patterns, weak concepts, ambiguity, conflicts, conflict avoidance, all that is going to affect your code.