
サーバーサイドにKotlinを導入して3年経った結果

サーバーサイドKotlinの導入から一年が経ちましたという記事から更に2年が経過し、アプリボットではサーバーサイドにKotlinを導入してから3年が経過しています。
その間に開発中であったタイトルはリリースを迎え、安定的に運用・更新が行われるようになりました。そこで、Kotlinを導入した結果、開発者体験はどのように改善されたか、そうでなかったかを振り返ってみることとしました。
この記事はアプリボット技術研究室、室長の斎藤が、Applibot Advent Calendar 2021の5日目の記事として執筆しました。
本記事の主張
- 既存開発者/新規開発者にとっても学習曲線がゆるやかである
- Javaの既存資産のKotlin環境への可搬性は高い
- IntelliJ IDEAの開発者体験の良さ
- プログラミング言語としての細かい機能が便利になっている
学習曲線のゆるやかさ
Kotlinの書き味は同じJVM言語であるScalaやClojureと比較しても驚きの少ないデサインとなっています。近年登場したプログラミング言語のパラダイムを一通り揃えた言語としては、学習曲線はゆるやかだと感じています。(Swift、Scalaなどと比較しても)
また、Kotlinを導入したプロジェクトにこれまで3年に渡りJava経験者や新卒採用者が参加してきましたが、どのメンバーにも違和感なく受け入れられているという現状があります。
当然のように既存資産と相互運用性がある
KotlinはJavaとの相互運用を前提としている言語なので、単一プロジェクト内でのKotlinコードとJavaコードの混在や、JavaでのGetter/SetterメソッドをKotlin側ではプロパティで扱えるようにするなど、Javaライブラリを扱いやすくする仕組みが取り入れられています。
またKotlin利用を前提としたライブラリは存在していますが、Kotlinプロジェクトを使用していてもJavaライブラリがデファクトスタンダード的に用いられている分野もあります。(例: Jedis)
弊社社内においても、過去のJavaの資産が現在でも利用できています。
IntelliJ IDEAという安心感
IDEやLSPにありがちな違和感(遅い、補完が壊れやすい、複雑なプロジェクトを用いたときに動作しない)などをほぼ見なくて済んでいます。
また、うまくコードを静的解析して「Kotlinならこういう風に書けるよ」というようなサジェストを表示してくれることもあります。
細かい言語機能が便利になっている
JavaからKotlinになって便利になっている言語機能で自分の気に入っている機能をいくつか紹介します。
1. KotlinのリフレクションAPIが便利
Kotlinのプロパティに対してのリフレクションが便利なだけではなく、ここにもJavaとの相互運用性が考慮された工夫が行われています。
https://kotlinlang.org/docs/reflection.html#bound-constructor-references
2. Delegateが書きやすい
クラスに関しての delegate、プロパティの delegate に関してもともにサポートしています。
Go言語のように手軽に delegate することが出来ます。
https://kotlinlang.org/docs/delegation.html
3. SAM(Single Abstract Method)変換
SAMインターフェイス(単一のメソッドのみを持つインターフェイス)を引数として取るメソッドの引数に対してlambdaで代用することができます。
こちらについては過去記事にて紹介しています。
4. Scope関数
いわゆる also
、apply
、let
、run
、with
、といわれるやつです。変数を null をガードしながら別のことを行いたい場合などに便利です。Scala の Option における、map
、foreach
を更に便利にしたものと言えると思います。
https://kotlinlang.org/docs/scope-functions.html
それ以外
1. 手軽さにやや欠ける
KotlinはJetBrains社が開発を主導しているので、IntelliJ IDEAのサポート非常に手厚いのですが、IntelliJ以外の開発支援ツール、つまりはLSPなどに関してはやや設定が煩雑な部分があったりして、コードを手軽に書くという点では他の言語に遅れをとっている部分があると思います。
ちなみにIntelliJ IDEAはCommunity Edition(無料版)でもKotlinの開発については行えるようになっています。
2. Web API開発をとりまく環境
ことWebアプリケーションに関していうなれば、AndroidOSのプラットホームのように開発環境の固定化がほぼありませんので、あえてKotlinを用いて新たにAPIアプリケーションを開発する場合は一考の余地があると思います。
この点が3年前と比較して最も変化した部分かもしれません。アプリボットやサイバーエージェントグループ内においてもJVM系言語以外の存在感が高まっています。
Java言語の経験者やJVM上の資産が多いなどの環境要因がアドバンテージとして大きい場合はKotlinを採用することが優位になると考えています。
まとめ
私自身、Scalaを気に入って用いていた時期がそれなりに長かったのでKotlinに対する懐疑心のようなものが少なからずあったのですが、Scalaを書いていた頃は「Scalaを書いている」という気持ちを抱きながらコーディングすることになっていたのですが、Kotlinを書くことに関しては難しいことを考えずにプログラムをアウトプットすることに集中出来ている気がしています。
KotlinはこれがあるからKotlinを使いたいという差別化要素が多いというよりは、シンプルさや既存の環境との相互運用から選ばれる言語であり、その違和感もとても少ないので逆に話題になりにくいのかなと思います。
アプリボットではすでに複数のプロジェクトでKotlinを使用したアプリケーションがリリースされており、結果としてAndroid環境においてはKotlinがファーストクラスの開発ツールとなって久しいように、Webアプリケーション開発においてもファーストチョイスとして申し分ないツール・エコシステムであると感じています。
この記事へのコメントはありません。