hamburger-tech-nits

主にプログラミングのNITSな話

FlutterKaigi2023参加メモ

flutterkaigi.jp

基調講演

  • 9年前からあったんだーとか、そういえば昔はOptional無かったなぁとか、知らなかった時期の変遷と懐かしい話とで初のオフライン開催一発目のセッションとしてちょうどよかった。アイスブレークのような感じで、少し一体感が出たような気がする。
  • 懇親会で知らない人と話すときの会話のネタにもなった。

Flutter アプリにおけるテスト戦略の見直しと自動テストの導入

https://flutterkaigi.jp/2023/sessions/df52c995-5fbb-4ff0-abbc-e6332af98797

  • アプリとしてのSREチームという概念が新鮮。単に障害を減らすという観点から一歩踏み込んでいるのはさすが
  • リファクタリングした結果の検知にはE2Eテストが役立ったという話(があった気がする。記憶が曖昧)。とあるレイヤーの変更は上位レイヤーから観測しないと分からないということなのか、全然関係ないのか。もう少し自分の中で整理したい
    • コストとしてはユニットテストだが、結局E2Eテストで振る舞いを見るのが、一番僕らが見たいテストに近い分活用の幅はあるのかも

出前館におけるFlutterの現在とこれから

https://flutterkaigi.jp/2023/sessions/5b402df3-9e5d-4c0b-80fa-61d9ba356594

  • 直前にブースでも別の方から話を聞けたので、話についていきやすかった。単に技術周りを整理しただけでなく、開発元が外部から内部に変わったということも難易度をあげる一員にはなってそう
  • Flutterがどうこうというより、チームビルディングを泥臭く頑張った結果大きな課題を解決できた、という話だった気がする。実際そうなのだろうし、それができるチームだからやれたんだろう
    • 個人的にもFlutterをチームで使うときは技術の良し悪し以上にメンバーが積極的かどうか?が重要だと考えているので、新しいプロジェクトをやる前に見直したい

Master of Flutter lifecycle

https://flutterkaigi.jp/2023/sessions/f76c37b8-172d-4072-ad4a-bd870bc15728

  • M3の人がM3MacでM3デザインスライドを使って発表してた。
  • ライフサイクルの関数は徐々に整備されている印象。ある時期を堺に新規の関数が知らないものばかりになっていた、ということに気づいた
    • Flutterだから何か特別なものが生まれたというよりもAndroidと似たような役割のIFも似た関数がFlutterにも追加された、という印象。

Dart のコード自動生成の仕組みと、コード自動生成のパッケージを自作する方法について

https://flutterkaigi.jp/2023/sessions/d9cc75af-a3a2-4d0e-af6c-f12aa143ba4c

  • パッケージ構成は理解できた。追っていくコードの順番もぎりぎりわかった。中身の実装は一回セッションを聞いただけでは無理だった。
    • これ以上無いくらい簡単に説明してくれたと思うので、あとは自分で時間をかけて理解を深めるだけ。なんだけど、普段と微妙に違う考え方が必要だと思うので腰が重い・・・
  • 決まったルールの関数を大量に生やしたくなることは山ほどあるので、できるようになれば一番レバレッジが効きそう。

Flutterアプリのセキュリティ対策を考えてみる

https://flutterkaigi.jp/2023/sessions/090ad5b8-7066-40e6-8ca8-58fff766f046

  • どこまで対策して何を保証するか・保証しないのは何なのかを言語化するのが第一歩。取り組む範囲を決める指針の一つとしてOWASPのような一般的な指標で整理していく
  • 技術が変わっても攻撃対象となるIFや目的は似ているので、結局ネイティブアプリでやっていることをFlutterでも同じように進めていくのが基本方針としてアリかも
    • 直接関係ないけど、セキュリティ周りは基本思想があまり変わっていない気がする。昔学んでおいてよかった

なぜわれわれは Riverpod を使うのか

https://flutterkaigi.jp/2023/sessions/0b32515e-2c80-45f4-8ea2-c6c269d2609f

  • Riverpodが飛び抜けて優れているというよりも使っている人が多いから設計の議論をショートカットし易い、という自分の考えと似たフレーズが書かれていて少し安心した
  • AsyncValue推しの話が初耳で重要な考え方だったので、早めにドキュメントを見直したい

その他

  • 真面目に取り組むとテストコードはプロダクトコードと同じくらい(かそれ以上)のボリュームになるので、テストコードも1つのプロダクトと捉えて運用コストかけるべきか?
  • 懇親会とかで聞いた感じ、Flutterをプロダクト開発に利用して大丈夫か?という話はまだあるっぽい。一時期のKotlinとかJetpackとかも辿った道だけど、もうちょっと何か信用できる何かがないと導入しにくい企業があるのかもしれない。