When Google announced it was making Kotlin an officially supported language for Android development, the team at Trov saw an opportunity we couldn't ignore. Kotlin offered us so many benefits which would accelerate our development and we made the decision to migrate from Java.
It’s all too easy to think a new framework, a new library or a new API will change everything and then jump right into it without a plan. But this path can lead to disorganization, frustration and confusion. To start taking advantage of Kotlin without creating chaos in our code base, and among our team members, we had to formulate a plan first.
Step one was to get the whole team onboard with the idea of adopting a new language. Learning new languages is always fun. What’s challenging is when you throw the aggressive timelines of existing products into the mix. Our goal was to get everyone to adopt a new language and still be able to meet those aggressive timelines.
Strategies don’t need to be complicated to be successful – they just need to be executed. With that in mind, the first step in our execution was to get everyone on the team excited about the new language. We accomplished this by sharing all of the great features Kotlin was bringing to the game. Honestly, getting excited about Kotlin wasn’t hard to accomplish. We’ve already shared a lot of the features we found to be instrumental in our decision to adopt Kotlin in a previous blog post. Once everyone understood the potential, we put together a specific process which we would then follow.
The next step was to start porting internal libraries to Kotlin to allow us to work with the language and tooling in small, constrained section of the codebase. The bundled Java to Kotlin converter was particularly useful when doing the initial pass.
While using the converter to port code gave the ability to see Kotlin in action, it wasn’t nearly as exciting or fun (and one of Kotlin’s stated features is fun) as writing new code. The final step before wholescale adoption was to start using Kotlin to write new unit tests. The goal was to provide the opportunity to the team to write new Kotlin code while still limiting the scope and impact.
Writing production code in Kotlin is the final step. We will start with writing new features in Kotlin and then convert existing Java code, with the intent of eventually having the complete codebase in Kotlin.
While converting an existing application to Kotlin is a lot more challenging, we’ve been able to adopt Kotlin from the start with some of our new internal Android projects. This gives the team more opportunities to learn from Kotlin without causing a disruption in an existing non-Kotlin app.
Throughout this transition, it will be imperative that we continue to heavily review both converted and new Kotlin code. Since Kotlin is somewhat new, it doesn’t come with a huge set of strong pre-established standards. For this reason, it is critical that we establish good habits, practices and standards early.
Let’s face it, even with a formulated plan, this transition won’t be perfect and we expect more challenges along the way. We will be documenting those and sharing them in an upcoming blog.