Dartによる言語統一開発とServer Side Dartの可能性
SHARES
この記事はnote.comからの転載です。
https://note.com/yamarkz/n/naec99fb5445c
Dartによる言語統一開発
筆者は現在の仕事でServer Side(以下、サーバーサイド)の開発言語にDartを用いている。このことを友人に話すと「厳つい選択をしているね」「そんなマイナーな言語でよく開発できるな」と言われることがほとんだ。
恐らく日本では弊社(10X, inc.)のみ？ 世界に目を向けてもほとんど見聞きしたことがない技術選択だと思う。少なくとも商用利用(事業としてソフトウェア開発の営み)でDart言語をサーバーサイドで100%利用しているというのは、自分の観測範囲内では見たことがない。 既に弊社は世界でも指折りな Dart Company 🎯 と言っても過言ではない。
↑ Web API リポジトリの言語比率
クライアントアプリもDartをベースにしたFlutterでiOS/Androidの開発を行っているため、日常で記述しているコードの90%がDartになっている。 残りの10%は管理画面とサイトコントローラーの実装で用いるTypeScriptとKubernetesのyamlくらいだ。なので、開発者はDartに習熟さえすれば良くなり、複数言語を跨いだ開発をするよりも遥かに良い効率で開発に取り組むことができる。
もちろん、クライアントの考え方とAPI開発の考え方は全く違うので、それらは理解しなければいけないが 、少なくとも言語による演算記述の違いであったり、イディオムの特徴などは開発文脈に関係なく踏襲できるため、容易に読み解くことができる様になる。
そして何より、言語が共通であることによって、頭の切り替えに必要なコストが激減する。筆者は昔クライアントをFlutterでDart、APIをRailsでRubyといった環境で開発をしていた経験があるが。その頃と比較すると、日々圧倒的な開発効率の高さを実感している。
言語統一の開発形態が生み出す恩恵は、思考のスイッチングコストやイディオム理解の効率性だけでなく、越境のしやすさにも大きく貢献している。
越境というのは、領域に囚われずに開発をすることで。1つの機能を実装するために、1人でクライアント、サーバー、インフラの全てを跨いで開発することだ。これには大前提に一般的なWeb API開発の考え方、バッチ処理開発の考え方、クライアントアプリ開発の考え方を理解を必要とするが、そこが理解できていれば、残る障壁となる開発言語の違いによる敷居の高さは、言語統一の形態によってなくなるため、格段に領域の越境がしやすくなる。
領域を越境できる1人のエンジニアと、各領域に張った3人のエンジニアが1つの機能開発に揃い踏みで取り組んだ場合を比較すると、前者の方が圧倒的に早く機能開発や改善のサイクルを回すことができる。それは調整コストがなく、意思決定を即断で行えて、軌道修正も容易になるからだ。 前提や背景にもよると思うが、開発効率の高さはソフトウェア開発の大きな武器であり、ソフトウェア企業における競争力の源泉になる。
クライアントとサーバーの言語を統一するという例は、Dart以外にもJava (Type) Script (React Native / Node.js)でも実現が可能になる。また、Kotlin Multiplatformなども選択肢として今後挙がってきそうだと個人的には見ている。
あまり類にみない開発形態ではあるが、言語統一による恩恵は大きく、 今後の開発組織における技術意思決定のロールモデルとして、有用な姿になると考えている。なお、異論は認める。
Server Side Dartの可能性
Dartという言語はサーバーサイドで使われることを前提としているわけではない。正確には、使うこともできるが、言語開発方針自体はクライアントアプリ開発を第一に考えて開発されている。これはFlutterで採用された言語であることに由来していることが一番大きい。
Flutterの開発は活発で進化も早く、既にコミュニティにも受け入れられた存在になってきているので、すぐに廃れることはないだろう。 これに依存する形でDartの繁栄も続くと考えられるが、それをサーバーサイドという前提で考えた場合には話が変わってくる。
では、Dartでのサーバーサイドの開発に可能性はあるのだろうか...？
問いの答えはYesだ。可能性はある。
ただし、"十分"ではまだない。それは既存のコミュニティの実績としての成果、そしてそこからくる自信的なものが他の開発言語と比較してみても大きく不足しているからだ。
十分ではないものの、可能性があると現時点で言い切れるのは、筆者が開発に携わっている商用サービスであるStailerというプロダクトでは、十分に開発が行えているからだ。g-RPCを用いたWeb APIの実装であったり、データ収集で用いるクローラーやバッチ処理のスクリプトなどは全てDartで実装しており、現状何事もなく利用できている。また、開発者の開発体験もGo言語に近しいものがあり、滞りなく行えている。
実績の不足が"十分でない"としている理由だが、具体的には他言語には当然あるようなクラウドサービスのライブラリがDart言語ではなかったり、あったとしても機能が実装されていなかったりする。 また、主要そうな(?)ポジションにあるライブラリでも、メンテナンスされているのかが怪しいコミット間隔のものが多い。
こういった懸念を押しのけて、自前で実装してしまうエネルギーがあれば無問題であるが。エネルギーを持ち合わせていない、またはその課題解決に割く余裕がない場合には、厳しい環境にあると筆者は捉えている。
Dart Language is Frontier
サーバーサイド開発でのDart言語は可能性があるものの、実績が少なく採用に踏み切るにはリスクと恩恵を得るまでのコストが大きいという見方が未だ9割方を占めていると思う。 それを表しているかの如く、ちょうど12月に行われるAdvent CalendarのDart言語の枠は見事にスッカスカである。
Dart言語の現状を見事に表すかのような、空き具合。逆に清々しい気持ちである。
ここまでの話を踏まえると、まるで狙ったかのような状態だが、ここまで書いてきた後に覗きに行った筆者も空きすぎてで驚いてしまった。 が、これが実際の現状だろう。。。
最後に
Dartという言語の2つの可能性について述べてきた。 考えを整理すると、"ソフトウェア開発を事業の営み”という視点と"開発コミュニティ成熟”の視点によるところが大きいという結論に達している。
ソフトウェア開発を事業の営みという視点で見ると、開発言語にDartを選択し、言語統一開発という形態をつくることは、高いアジリティを生み出せる状態に繋がり、それは結果として事業自体の大きな競争優位性になるという点に、大きな可能性を感じている。 これは今後の開発形態のロールモデルになりうる だろう。
一方、開発コミュニティという視点で見ると、不足していることが多く、不便に感じるかもしれないが、課題を上手く解決する機会に溢れていると捉えれば、実装機会に恵まれている環境と捉えることもできる。 既存の出来上がったコミュニティで満足するのも良いが、何もない場所で良い物を作る、より良くする機会に溢れているというのは、開発者としての腕を上げる絶好の機会になる はずだし、筆者も日々そういった考えで開発に臨んでいる。
以上、Dartという言語の話を紹介してきました。 久しぶりに何か書こうかと思い、筆を取って出てきた内容が今回の主題です。何か感想などあればいただけると嬉しいです。