Day1

Modifier.Nodeを使いましょう

旧仕組みのModifierメソッドチェーンやcomposedの場合では管理するCompositionツリーが大きくなってしまいパフォーマンスに影響を与える
Modifier.NodeではonAttach,onDetachなどが提供、isAttachなどいくつかのプロパティは onAttach~onDetachの間でしか呼び出されないことの注意
composedを利用している箇所をModifier.Nodeに置き換える

今回全てのセッションを楽しみにしていましたが、中でも特に楽しみにしていたセンションの1つがこちらでした。

立見であんまりメモとれず - AndroidViewとComposeの相互運用でスクロールを伝達させる方法はいろんなシーンで役立つ情報に思った

MVIアーキテクチャは経験なかったが、結構チーム人数が多い場合に有効そうなアプローチに思えた
データレイヤーとUIレイヤーでチームが分かれている場合などに並行して作業を進められる利点がある
Constractから渡されるStateに合わせてUIを構築する約束事ができるので漏れは少なそう
割とやりたいことに対しての工数が膨らみそうだったりバグ修正が辛そうな感想を持ったが、セッション内では小さい変更がしやすいと紹介されていたのでまだ自分の理解度は低いかもしれない
UMLが仕様書になる点はメリットとして大きそうに思えた

DeNAのSWETチームの方の発表で今回特に楽しみにしていたセッションその２！

いいユニットテストとは
- アプリの変更の容易性を保つため、アプリの成長 = ビジネスの成長。E2Eですべてをカバーするのはむずかしい。
- 開発者から信頼
- グリーンであることを保つ
- 変更が容易
- テストの実行が簡単
- リグレッションを検知しやすい
テストダブルのトレードオフ
- 実装が変わった時にテストダブルも修正する必要がある
- 使い方しだいではリグレッションやご検知に悪影響をあたえる可能性がある
- 実オブジェクトとテストダブルの互換性を保つ維持するコストがかかることを理解する
- テストダブルの容易さが維持を忘れる危険性がある
改善方法
- HumbleObjectパターン
  - オブジェクトからロジックをできるだけ切り離すパターン
  - ViewModelからロジック部分を切り離したり
- Createtion Methodパターン
  - テスト間でインスタンス共有
- 何をテストしているか理解しやすくする
  - 準備、実行、確認を区切る
  - 関数名を変える
- パラメタライズテスト
  - 有効なケースと無効なケースなどでパラメタライズテストを分ける
  - テストケースの意図を説明するパラメータを追加する

Compose Multiplatform Wizardで楽々プロジェクト作成可能
API通信はKamelを使う。中でKtorに依存している
KamelImageでネットワーク上の画像を読み込み描画
Voyagerでナビゲーションを実現
KMPはナビゲーションが公式でライブラリがなく辛みを感じていたのでVoyagerいいなと思いつつ、導入したら依存性が高そうなので覚悟が入りそうだなと思った（ライブラリとして捨てにくそう）

個人的にはレビューファースト意識持っているので共感性高いセッションだった

DMMポイントクラブ、DMM TV、DMM ブックスの3チームのレビューにアンケート
色々な取り組みを紹介されていたが、全てに共通していえることは「レビューする人にとってどんなPRがレビューしやすいか」というレビュー上でのコミュニケーションと思いやりに溢れる内容だった
レビュータイムやレビュワーにアサインされた人に通知など仕組み的な施策も紹介