How’s Your Codebase Looking? 5 Best Practices for Android Development

There are many things to consider when building an Android app. Implementing best practices can help you and your team working on any codebase (new or legacy). Best practices provide many benefits and can help:

• promote a clean, uniform codebase
• speed up new team member onboarding
• assist you in writing better quality code
• generally make things easier for you and your teammates

Below is a small list of things that we implement and work well for us at Bottle Rocket Studios :)

1. Share Run Configurations with the team

• Create custom run configurations that match gradle tasks executed by your CI/CD Pipeline, allowing you to smoke test that your code is good to go before having it fail when ran on the build server. Find this one and others at https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#run-configurations-explained
• Allows Run Configurations to be created by any team member and shared with all team members.
• You’ll need to check .idea/codeStyles/* into the git repo, potentially removing any overly broad .gitignore rules on .idea/.

Source: https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#idea-folder-values-checked-into-the-git-repo

2. Share project code style with the team

• Ensure that code formatting uses the same rules regardless of Global IDE settings.
• You’ll need to check .idea/codeStyles/* into the git repo, potentially removing any overly broad .gitignore rules on .idea/.

Source: https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#idea-folder-values-checked-into-the-git-repo

3. Use static analysis tools to improve code hygiene

• ktlint is great to normalize kotlin code style and prevent bikeshedding discussions.
• detekt is useful to bring code smell forwards and allow for team discussion if/when the default values for rules should be tweaked.
• Android lint is also useful to callout any Android related issues that may crop up in the codebase.

Source: https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#ktlint

4. Add FIXMEs and TODOs

• Add FIXME comments when something must be addressed before the next release.
• Add TODO comments as you write code if you have ideas that could improve the codebase.
• Both FIXMEs and TODOs can have corresponding backlog tickets to bring visibility to the wider project team.

Source: https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#fixmetodo-comments

5. Modularize your codebase

We typically start out using at least two modules, one app module and one data module. As the codebase grows, additional modules can be added.

• The app module (Android application) can contain UI and code that depends on the Android framework.
• The data module (Android library) should contain any Repositories, Network and Domain Models, and Utility classes among other general business logic holders.

Additionally, when using Compose it can be useful to have an additional compose module (Android library) where all of the compose screens live to decrease time to render previews.

Source: https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md#modularization

Find additional info on these best practices and more at https://github.com/BottleRocketStudios/Android-ArchitectureDemo/blob/develop/docs/BEST_PRACTICES.md

The more that you start to ritualize the mundane, the more you will be able to spend your time and energy on the exciting parts of development such as solving business problems and improving user experience.

Talk with your teammates about what changes you’d like to make to improve your codebase and the process for working on it!

 This article was originally published on Medium.com