こんにちは。コミュニケーションアプリ LINE のクライアントを開発している石川です。 12月10日に開催された、Kotlin Fest 2022 で 可読性から見たKotlinの言語機能 -「使いたい」の、その先へ。 というタイトルで発表しました。
この発表で最も主張したかったことは、「Kotlin の言語機能は便利だが、『使うこと』そのものを目的としてしまうと、可読性や頑健性を下げかねない」点です。Kotlin の言語機能のアンチパターンとその理由を示し、言語機能を使いたいから使うのではなく、目的に応じた適切な使い方は何かを紹介しています。
- セッション動画: https://www.youtube.com/watch?v=QGh-a1gg6nk
- スライド: https://speakerdeck.com/line_developers/kotlin-language-features-and-readability
このブログ記事ではその登壇の過程をレポートします。
Kotlin Fest とは
Kotlin Fest は、プログラミング言語 Kotlin に関するトピックを中心とした技術カンファレンスです。新型コロナウィルス感染症の影響で2020年のイベントが中止して以来の3年ぶりとなる開催で、待ち望んでいた人も多かったと思います。今回はオンラインイベントとして開催され、気軽にセッションを視聴できる環境でした。
Kotlin と聞くと Android のイメージが強い人も多いかもしれませんが、Kotlin Fest では Kotlin 言語固有のトピックの他、サーバサイドや Web フロントエンドの話題も多い印象を受けました。
プロポーザルの選定
Kotlin Fest では他の多くの技術カンファレンスと同様に、セッションのプロポーザルを広く募集し、その中からセッションを採択します。応募したプロポーザルが採択された場合、採択通知が10月末でイベントが12月10日なので、1ヶ月以上の準備期間がありました。
しかし、私の場合は抱えているタスクの都合上、11月は十分な準備時間を確保できず、Kotlin について新しい事項を調査することは難しい状況でした。そこで、今回応募するプロポーザルは、自分やチームの知識としてすでに蓄積されているものに基づいたものにしようと決めました。
都合が良いことに、クライアントチーム内で行っている review committee という取り組みを利用できました。Review committee とは、「すでにマージされたPR」を再度レビューし、プルリクエスト作成者やレビューアにフィードバックし、そこで得られた知見を weekly report という形で共有する活動です。Weekly report で取り上げるトピックは、プログラミング一般・クラス設計・状態管理・アルゴリズム・テスト・コードレビュー・プルリクエストやコミットの作り方など多岐に渡ります。この中には、Kotlin の言語機能に特化した話もあるため、それを集めることで一つの発表として構成できます。Weekly report の共有は2019年末から行っている取り組みで、すでに 100 を超える report が蓄積されていたため、分量としては全く問題ありませんでした。
なお、review committee に関しては DroidKaigi 2021 の 長く生きるコードベースの「品質」問題に向き合う というセッションで説明しています。併せてご視聴いただけると嬉しいです。
採択後の準備
ありがたいことに、私のプロポーザルを採択して頂けたため、早速...ではなく他のタスクを片付けてから、ぎりぎりになって準備に取り掛かりました。準備として必要なことは、発表の形式の決定・トピックの選定・スライドの作成です。
発表の形式
発表の形式は、weekly report を踏襲することにしました。Weekly report ではまず、問題のあるコードを提示します。そして、そのコードの「何が問題か」と「どう直せばよいか」をチャットで参加者に答えてもらい、その後 report の続きを解説しています。ただし、この形式そのままではかなりの時間を要するため、本発表では「問題のあるコードを提示し、どこに問題があるかを10秒間考えてもらう」という形式に簡略化しました。考えてもらう時間を設けることで、発表にメリハリが付き、視聴者の集中を適度に維持することができるのではと考えています。
トピックの選定
Weekly report から Kotlin の言語機能に関することを選べば良いのですが、その際に以下の2点に注意を払いました。
- コードの理解に必要な背景
- 問題の難易度
コードの理解に必要な背景
コードを提示する以上、まず視聴者に理解してもらわなければなりません。Kotlin Fest に参加される人は Android クライアントエンジニアとは限りません。また、私の発表内容は Android 固有のもはでもないため、「Android を知らないと理解できないコード」は避けるべきで、ましてや「LINE アプリの背景を知らなければ理解できないコード」はもってのほかです。また、視聴者に長時間コードを読み続けてもらうことは現実的ではないため、「概要をぱっと見で理解できるトピック」を選定する必要があります。幸いにも、weekly report を書く時点で一般化しているケースが多かったため、適切なトピックが選べたかなと思います。
問題の難易度
問題の難易度として、基本的に「なんとなく何がまずいか分かるけれど、うまく説明できない」程度を目指しました。さっぱりわからない問題を聞かれ続けるのは視聴者にとって苦痛になりますし、逆に新しい知識を全く提供しない発表は価値が薄くなってしまいます。実際にコードレビューで見たときに、「問題があることは分かるけれど、何て説明したらよいか迷う」という状況に対して、答え方の1つを提示することをこの発表の価値と置きました。
また、視聴者がどの程度 Kotlin に慣れているかは予想がつかなかったため、問題ごとに難易度をある程度変えることにも気をつけました。「nullable なコレクションを引数に取る」という広く知られたアンチパターンから、「定義域に重なりがある状況で sealed class と data class を組み合わせて使う」という一目ではわかりにくいアンチパターンまでを取り上げ、「全部全く分からない」や逆に「全部簡単すぎる」ということが少なくなるようにしています。（なお、「定義域に重なりがある状況で sealed class と data class を組み合わせて使う」アンチパターンは、sealed class 自体を解説する記事として頻出してしまう程度には、気が付きにくい問題です。）
スライドの作成
多くの場合、スライドを作るときはストーリーを立て、不必要な話題の跳躍が起きないように気をつけると思います。しかし、今回の発表では、各言語機能に対していくつかのアンチパターンを紹介するという形式をとっています。そのため、ストーリーが個々のアンチパターンで閉じてしまい、発表全体を通したストーリーが立ちづらいです。全体のストーリーがなくても、個々の話題の独立性が高ければ、それぞれを理解してもらうことは可能です。ただし、視聴者に負担をかけないためには、「今どの階層の話をどの程度進めているか」を分かりやすくする必要があるでしょう。特に今回は、言語機能が複数あり、その中でアンチパターンが複数あるというネスト構造になっています。Kotlin の型で書くならば Map<Feature, Set<AntiPattern>> でしょうか。この構造で「今何を話しているか」をわかりやすくするためには、少し工夫が必要そうです。
そこで本発表のスライドでは以下の2点を行っています。
- 階層で背景を変える: 個々の言語機能の話題と、トップレベルの階層（背景、まとめ、トピック一覧などの）で背景を変えています。特に言語機能の話題が転換するごとに、背景の違うトピック一覧のスライドが挟まることで、発表の進捗が節目で分かるようにしています。
- 話題転換時のアニメーション: 個々の言語機能の話題では、最初に機能のそのものを概説し、最後にまとめのスライドを入れています。そして、その概説とまとめのスライドをトピック一覧と関連づけられるようにアニメーションを入れています。こうすることで、話題転換時にそれが分かりやすくなっていることを期待しています。また、話題転換のアニメーションは2種類使い分けることで、階層の違いを表現しています。こちらについては、文字による説明では限界があるため、ぜひアーカイブ動画をご視聴ください。
登壇
最初に軽く発表練習をしたときは、まだ未完成なスライドがあるにも関わらず、制限時間の45分を超えてしまいました。そこで登壇本番では、話題の削減をし、話すスピードを少し上げたのですが、結局は40分より早く発表を終わらせてしまいました。もう少しゆっくり話し、かつ、省略した話題をいくつか戻しても良かったかなと反省しています。
最後に
視聴してくださった方々や Kotlin Fest のスタッフの方々に改めて感謝いたします。 「ためになった」などのありがたい感想をいただけて、視聴者の役つ立つ発表ができたのかなと思います。