DroidKaigi 2023 Day2 セッション概要&感想

はじめに

DroidKaigi 2023に参加してきましたので、オフラインで聴講してきたセッションの概要とその感想についてまとめていきます。
Day1の紹介もしてますのでよろしければご覧ください

MVIに基づくStateMachineアーキテクチャ：KMMとJetpack ComposeとSwiftUIを組み合わせる

概要

クロスプラットフォームテクノロジーであるKotlin Multiplatform（以後KMP）と相性がいいアーキテクチャであるMVIを導入し、KMP, Jetpack Compose(Android用のUIライブラリ), SwiftUI(iOS用のUIライブラリ)の3つをProcessor、Reducerを用いてMVIアーキテクチャを構築するという内容でした。

感想

Processor, Reducerを用いたアーキテクチャの構築はUIレイヤーがなくてもデータレイヤー部分から作っていけるのは複数人での作業に向いてそうだなと思いました。ただ少しのUI追加だったり色々なところに関係するのでバグ修正が難しいのでは...?とも思いましたが、セッション内ではUMLからKotlinのDSLを作ることで解消しているのだとか。UMLがそのまま仕様書になるのは便利でいいなと思いました。

Androidの『音』を制御する

概要

Androidの音を再生する方法、音量を変更する方法、サイレントモードの端末差異についての話でした。特にサイレントモードの端末差異についてはサイレントモードの動作の差だけでなく、サイレントモードにした後に戻せるかどうかまで端末ごとに差があるため、事前にユーザとのコミュニケーションが必要になるという解説がされていました。

感想

発表資料が専門用語からコードベースまで非常に詳しくまとまっていたため、今後音を使ったアプリを作る場合には参考になる資料だと思いました。
また、サイレントモード時の端末差異は僅かな差というわけではなく、クラッシュするものから音量設定が変わるものまであるので、コード側からサイレントモードにするようなことは開発者側の意図しない動きになる可能性やユーザの体験を損ねる可能性を考えてしない方がいいなと思いました。

Androidアプリの良いユニットテストを考える

概要

• 再現性と独立性があり、テストが安定している
• 迅速なフィードバックが得られる
• テストしたい箇所のテストをするのが容易
• リグレッションを検知できる
• テストによる誤検知が少ない
• テストコードを保守しやすい

この6項目が良いユニットテストの特徴であり、これを目指すためのmockの使い方とその注意点や自動化による開発効率と安全性の両立についての内容でした。

感想

mockの使い方や全ての動作でmockを使うのではなく、mock化してもいいところと実オブジェクトを使う場所を分ける必要があるのはユニットテストを作る上で参考になりました。また、ユニットテストの自動化は自分では気がつかない既存コード修正の穴を埋める手助けになるので、サービスをより良くしていくために必要だと再認識しました。
セッションには具体的なテスト自動化の方法までは発表されていませんでしたが、GithubActionsを使えばユニットテストを走らせることもできるので、PR作成時等に走らせられればレビュワーの負担軽減にもなりそうだと思いました。

様々なユースケースに利用できる "パスキー" の導入事例の紹介とUXの課題解説

概要

パスワードなしで認証を行うことができるパスキーの技術ベースになっているFIDOについて、パスキーを実際に使っているYahoo! JAPAN, Githubのサインインのフロー、Androidで使用する場合の方法についてのセッションでした。
特にAndroidで使用する際の解説では実際の画面状態からコードベースでの実装方法まで解説されており、特にパスキーに慣れてないユーザのためにもエラー画面を表示するよりも、スムーズにフォールバックやリカバリーへ誘導することが重要とのことでした。

感想

自分は単純にパスワード使わずにサインインができるの便利だよね！　としか考えれていませんでしたが、Androidアプリ上で実装するためには技術的な方法だけでなく、UXのことも考えて動線を作る必要がありそうだなと感じました。パスワード入力が不要になる手軽さは欲しいですが、その手前の登録段階がシームレスでなければユーザに余計な負担を背負わせる形になりかねません...

突撃！隣のコードレビュー

概要

DMMのいくつかのチームのコードレビューに関する取り組みのセッションです。

• チームとしての取り組み
  • DMMポイントクラブ
    • 実装前に設計のレビューで実装の流れを共有
    • 設計段階からPRを作り、PRテンプレートに設計時のセルフチェック箇所、実装後のセルフチェック箇所の両方を設けて設計と実装の差をわかりやすくする
    • チームとしてコードレビュータイムを1日2回、1回30分設ける（1回は口頭）
    • 【Good】コミュニケーションが活性化して気軽に質問できるようになった
    • 【Bad】PRが溜まる
  • DMM TV
    • 1PR500行の制限
    • PRに修正内容や影響範囲を記載
    • PRでコメントでコマンド打ってビルドチェック
    • 【Bad】特定分野でレビュアー知識に偏り、修正箇所がわかりづらいと放置され気味
  • DMMブックス
    • レビュー依頼をチーム全員にして、2人以上からApproveもらったらmerge
    • 1PR200行の制限
    • 設計段階で仮実装を行い、より具体的な工程と工数の割り出し
    • 設計レビューを行うことで実装レビューとの意識の差をなくす
    • 【Bad】 確認が手動で質が安定しない

その他レビューする側、される側として個人で意識していることについても紹介していました。

感想

全体的に設計段階をかなり重視しているように感じました。確かに設計段階でしっかりとしたものができればあとはそれにそって作るだけになるので、実装レビューの負担軽減にもなります。
今回は3つのチームでチーム単位でやっていることと個人でやっていることをかなり詳しく紹介いただけたので、これを元によりよいレビュー体制が模索できればいいなと思いました。

Material 3 やめました

概要

Material3（以下M3）のデザインシステムは色管理の複雑さ、ブランドカラーを使っている場合のDynamic Colorとの相性の悪さ、Custom Colorのダークテーマ未対応などが原因でデザインカラーをそのまま使うことをやめ、デザインシステムを自作し、M3のコンポーネントは使うかたちにしたという内容でした。

感想

セッション発表者がDroidKaigi 2022でM3への導入についての発表をされていた方だったので、セッションタイトル時点で笑ってしまいました。
聞いてみれば納得の内容。やはりM3はブランドカラーとの相性悪いですよね...
M3のcomponentToken以外はそのまま使って独自のデザインシステムを作成したそうです。ただしM3のコンポーネントは使うためにコンポーネントのカラー反映部分だけは独自デザインシステムでラップするかたちにしていました。
デザイナーさんがいないと全体作業的にかなり厳しそうだと思いましたが、カスタムのUIをあまり使わずに基本のコンポーネントを多く使っているシンプルなアプリにとっては導入の手助けになったのではと思いました。

さいごに

DroidKaigi 2023 Day2のオフライン聴講してきたセッションは以上になります。
これ以外にもライブ公開していたセッションは今すぐにでも見れますし、これから各セッションは順次動画化されて公開される予定とのことでした。
Droid Kaigiも年々規模が大きくなっている気がします。来年の参加も楽しみです。