Defining Best Practice for Kotlin Development

Written by Matti Frimodig, Senior Software Developer @ Unity

A case study of why our team made the developer driven choice to switch to Kotlin and how we strive for quality through defining best practices.

In this blog post I will go through why our team of professional Java developers chose to move all future development to Kotlin, go through the experience we had and share our internal best practice document in the hopes that it will be useful to someone going through or contemplating a similar switch.

Background

Within Unity we have a bunch of internal tools to facilitate monetary transactions between Unity and our customers, i.e. developers and advertisers.

Our team, known internally as the Wallet team, exists to build the services that help Unity pay out advertising earnings to developers correctly and on time as well as ensure that customers can easily purchase Unity products and services, such as the aforementioned advertisements, without waiting for manual money transfer processes.

The team itself works with multiple technologies and programming languages, but the main language for backend development was Java until spring 2019 when we made the decision that a new service we began work on would be written in Kotlin. At that point I was the only member of the team with experience working professionally with Kotlin, but my insistence on it being the perfect solution and the lure of working with a trendy new technology swayed the team to give it a try.

Why Kotlin

In my personal experience Kotlin strikes the perfect balance of what I had been looking for in a new programming language to use for my day to day work. It isn’t some academic proof of concept for a new programming paradigm, but instead designed from the ground up to be used in real word applications everywhere where you would use Java. It borrows ideas and concepts liberally from functional JVM languages that have preceded it while remaining close enough to Java to allow me to utilize my extensive Java experience and even more importantly maintain smooth interoperability with existing libraries and codebases.

If you are not familiar with Kotlin as a language, or how it compares to Java, you can read more about it here, but some of the highlights that I’d like to point out are: static typing with type inference, null safety, having collections and variables immutable by default and reduced boiler plate code. Overall Kotlin provides us a way to write code that is safer as well as easier to read and maintain.

Our experiences

The change to Kotlin was not immediate. Initially some team members were working on the new service with Kotlin while others continued feature development on the old services with Java. This approach came with the drawback of the new service becoming technically isolated as team members that had not yet worked with Kotlin were apprehensive about working on the new project or even reviewing the code as they felt they lacked both the knowledge of how the language worked and the practical experience to separate the logic from the syntax and to spot bad patterns and feature misuse.

We were able to rectify this issue with two things: somewhat luckily it was possible for all of the team to work on new projects on which we were able to utilize Kotlin and we started putting together the best practice document, which you can find in the next section.

In the combination of changing the development language and having new greenfield projects to work on led to a burst of new libraries being introduced to the code base as with many of them we had to evaluate how well they worked together with Kotlin. While all of the libraries we had been using would have still worked, several of them were switched favoring ones that provided a more idiomatic interface or were simply more lightweight single responsibility libraries. One of the more major changes that came out of this was the decision to move from Spring Boot to a combination of Ktor and Koin that gave us everything we had used Spring Boot for while introducing far fewer unnecessary chained dependencies.

Due to the gradual process of finding new best practices, and adopting new frameworks while developing in parallel, has led to some technical debt. Fortunately the team’s focus on code quality and maintainability helped keep this at an acceptable level throughout the process.

Best practice

To help the team work in a uniform way with Kotlin and help both the current developers and new joiners find useful features that they might not otherwise be using, I started putting together a best practice document; to act as both a quick introduction to Kotlin for Java developers and as a living document of what features of Kotlin we want to use in our team and how to use them. We are publishing this document here as it currently exists. It is written for our particular use case, and we are not claiming to define best practice for the language overall, but much of it can hopefully be applicable to other projects.

The document is a living document, available here, and will be updated as we fine tune our practices.

Our advice for anyone thinking of adopting Kotlin

There are many reasons to start working with Kotlin as opposed to using another programming language. For our team it was the ease of switching from Java combined with the improved safety and readability that made the Kotlin the right choice for us. Whenever adopting a new technology you should remember to ask yourself what the problem is that you are trying to solve with this technology and if there is something else that will solve it for you even better. You may find that for your team Kotlin isn’t the right solution, but we believe that for a lot of teams it will be. There is a reason why Kotlin is one of the fastest growing languages out there.

In retrospect much of the problems we had early on could have been avoided if we had started off by creating the best practice document and had everyone on the team working together on the language ASAP. If possible, have some of the engineers in your team act as new technology ambassadors, giving them time to familiarize themselves with the language so they can act as support for the rest of the team when actual feature work begins.

If you want to try out Kotlin without fully committing, a good place to introduce it to an existing project are the unit tests. Due to the interoperability with Java it is also feasible to start using Kotlin in an existing Java project converting existing classes to Kotlin when they need new functionality. IntelliJ IDEA also provides a convert to Kotlin functionality for existing code, but it is good to be aware that it will not generate Kotlin as someone familiar with it would write but rather retains most of the Java idiosyncrasies.

If you would like a deeper dive into Kotlin there are many online resources, but I would especially like to recommend the book Effective Kotlin by Marcin Moskala, which tackled the subject of best practice for Kotlin and influenced the several of our selected practices.

If you are interested in working with us in creating quality code that you can be proud of, whether with Kotlin or any of the other languages we are using, check out our open positions in Engineering today!