はじめに
こんにちは。
株式会社コズムCTO内藤と申します。
バックエンドの技術選定にお悩み中やコズムに興味を持ってくださった開発者の方に向けて、
弊社バックエンド開発におけるメイン言語として Kotlin/Ktor を採用したときの着眼点についてお伝えできればと存じます。
プログラマー三大美徳のひとつ “laziness” にのっとり、Kotlinとは？といった内容は省きます。
きになるかたはぜひオフィシャルサイトをご確認ください。
課題感
まずは弊社の状況とバックエンド開発で抱えている課題感をお伝えできればと存じます。
弊社は創業から1年半ほど、さらには従業員の平均年齢も26歳程の非常に若い会社です。
若さを生かした体力・勢いはありつつも、若さゆえにジュニア〜ミドルクラスの開発者が多く、
それぞれが得意な言語・フレームワークもまちまちです。
幅広い環境に適した人材がいて、プロジェクトに適した言語選択をできることは大変良いことです。
しかし、プロジェクト毎に言語・設計が変わってしまうと初動が遅くなる、人により成果に偏りがでやすいといった課題がありバックエンドの技術を共通化していこうとなりました。
選定時の着眼点
選定にあたっての着眼点は次のとおりです。
優先度高
↑
- 静的型付け/コンパイラ型言語
- ライブラリが充実している
- 情報量
- 開発環境が充実している
- 利用シーンの広さ
↓
優先度低
静的型付け/コンパイラ型言語
何よりも優先したのは静的型付け言語かどうかです。
古くは CGI 時代の perl から昨今の Ruby, Python に至るまで、
バックエンド開発においては動的型付け言語が主流に思えます。
そのためライブラリの充実・開発環境の充実など申し分ないのですが、
中規模・大規模開発でシステム全体を全員が把握できなくなってくると型が定まらないことによる弊害が出てきます。
例えば、ユーザークラスに都道府県プロパティがあったとします。
動的型付け言語の場合、都道府県プロパティが文字列なのか？それとも都道府県番号のような数値なのか実装を見るまでわかりません。静的型付け言語であれば、クラス定義だけ見れば補足資料なく理解できることが増えてきます。
またコンパイラ型言語を選択することで、実行前にある程度動くことが保証されます。
結局 linter や test で担保するから関係ないのでは、
といった議論もあるかもしれませんが責任範囲の話は主題ではないと思うので割愛します。
ライブラリが充実している
こちらも重要視しました。
そのままですが先人等の残してくれた最強の武器が多いに越したことはありません。
情報量
情報量と書きましたが活発度の方が正しいかもしれません。
情報量が多くても、昨今の目まぐるしい進化に対応できないと開発効率は激減します。
そのため、新鮮な情報が多い環境が好ましく思います。
開発環境が充実している・利用シーンの広さ
こちらに関しては優先度としては低いですが次のようなことを考えました。
バックエンド開発者の多くが1日の大半をエディター・IDEを利用し過ごしていると思います。
それだけ長く触れるものなので、個人の嗜好を尊重し快適な環境構築ができることが望ましいと思います。 Apexとか方言的な言語だと辛いですよね？
今回はバックエンド開発を想定した選定ですが、同じ言語でフロントやネイティブでも利用できれば言語知識の再利用性は高まります。参考程度ですが頭の片隅で考えていました。
選定結果
上記を踏まえて表題の通り言語は Kotlin、フレームワークは Ktor を選択しました。
Kotlin
原則静的型付け言語である (dynamic 型もある)
Java の豊富な資源を利用できる
Kotlin の開発元である JetBrains が開発環境も提供している
(ネイティブアプリからサーバーサイドまで幅広い利用シーンがある)
Ktor
Kotlin と同じ JetBrains が開発しているため、言語・開発環境との親和性が高い
規模問わず利用しやすい
RoRのように制約の多いFWは小規模開発だと機能過多に思えます。昨今流行りの薄いFWのため、小規模の時は小規模なりの実装がしやすく思います。
中規模・大規模の場合、コーディング規約などの作成は必要ですが、柔軟な構造のため会社全体のバックエンド開発者の状態にあわせた最適化がしやすく思います。
おわりに
以上いかがでしたでしょうか？
参考になれば幸いです。
こちらの詳細についてはまだまだ話したいことは尽きません。
その②ではKtorのディレクトリ構造についてご紹介できればと思います。