自社テンプレートを実践で使って感じた強みとツラミ

Transcript

1. 自社テンプレートを実践で使って感じた 強みとツラミ おだてつ
2. 自己紹介 おだてつ 所属チーム：Flutter, BE
 
 GitHub：@Aosanori
 
 趣味：カメラ, テニス, 筋トレ, クソアプリ開発 
 
 備考：髪の毛は天然パーマです 🥦
 2
3. ~会社紹介~ 3
4. ゆめみについて みんなの知っているあのサービスも ゆめみが一緒に作っています 4
5. ゆめみについて イベント 5
6. ゆめみについて 大喜利アカウントとして有名 😅 6
7. アジェンダ 1. 自社のテンプレートについて 2. 実際に使って感じた 強みとツラミ 3. 今後の展望 4. まとめ 7
8. アジェンダ 1. 自社のテンプレートについて 2. 実際に使って感じた 強みとツラミ 3. 今後の展望 4. まとめ 8
9. 1. 自社のテンプレートについて 概要 Flutter モバイルアプリケーション開発を迅速に開始しつつ、 一定の品質基準を保つための中・大規模向け標準テンプレート Flutter モバイルプロジェクトテンプレートとは？ • 開発初期コストの削減 • 環境の一貫性確保 • 品質の標準化・ベストプラクティスの共有 • 効率的な開発サイクルの実現 • スケーラビリティとメンテナンス性の向上 効果 9
10. 1. 自社のテンプレートについて 使い方 Create a new Repository をクリック プロジェクト名を設定する issue に沿って初期設定を完了させる 10
11. 2. 実際に使ったわかった強みとツラミ ディレクトリ構成 (2024年6月時点) 同時並行で進めやすいマルチパッケージ構成 • apps ◦ app ▪ アプリ本体 ◦ catalog ▪ 開発者やデザイナーがコンポーネントを 個別に視覚化するために使用 (UIカタログとか) • packages ◦ cores ▪ アプリケーション全体で使用される 共通な機能 ▪ ログインや課金など ◦ features ▪ アプリケーションを横断しない特定の機能 ▪ UI、ビジネスロジック アプリ本体 WidgetBook 共通機能 特定の機能 11
12. 1. 自社のテンプレートについて アーキテクチャ (2024年6月時点) • app ◦ アプリ本体、Navigator など • features ◦ 特定の機能を構成する Widget、 状態を保持する Provider や Model、 ビジネスロジックなど • domain ◦ feature に閉じない状態、状態を保持する Provider、Model、Serviceなど Feature-Firstで 共通部分はcoresとして切り出した構造 12
13. 1. 自社のテンプレートについて アーキテクチャ (2024年6月時点) • infra ◦ API Client 等 • core ◦ ログ、共通の例外、Analytics 等 • catalog ◦ WidgetBook の UseCase • design system ◦ 共通コンポーネント、画像などの asset 等 Feature-Firstで 共通部分はcoresとして切り出した構造 13
14. 1. 自社のテンプレートについて 使用パッケージ (2024年6月時点) Melos • 複数の Dart/Flutter パッケージを管理するための CLI ツール • 依存の管理や各モジュールのバージョン管理の煩雑さを解決 • マルチパッケージ構成の管理が容易に • melos bootstrap コマンドで依存関係を まとめてインストール可能 • 各種開発用スクリプト（ビルドやテスト、 コード生成など）も Melos 経由で一括実行可能 開発初期コストの削減、環境の一貫性確保 スケーラビリティとメンテナンス性の向上 効果 melos.yaml 14
15. 1. 自社のテンプレートについて 使用パッケージ (2024年6月時点) FVM • Flutter SDK のバージョン管理ツール • プロジェクトごとに Flutter SDK のバージョンを固定しチーム全体で統一可能 • クローン後にターミナルで fvm use --force を 実行することで、FVM がそのバージョンの SDK を 自動インストール可能 • チーム全員が同一バージョンの Flutter で 開発・ビルドを行うことが保証 開発初期コストの削減、環境の一貫性確保 効果 .fvmrc 15
16. 1. 自社のテンプレートについて 使用パッケージ (2024年6月時点) yumemi_lints • ゆめみが推奨しているリントルール集 • Dart や Flutter のバージョンごとにリントルールをまとめている • テンプレ内では事前に競合が解決された recommended.yaml がデフォルトなので、 開発初期からコードの一貫性を保てる • Flutter または Dart バージョンを更新時は dart run yumemi_lints update のみで リントルールの更新が可能 スケーラビリティとメンテナンス性の向上 効果 16
17. 1. 自社のテンプレートについて 使用パッケージ (2024年6月時点) dio • HTTP クライアント/ネットワーク通信パッケージ • グローバル設定やインターセプター、リクエストのキャンセル制御、 ファイルアップロード /ダウンロード対応 ◦ http より最初からついている機能が多い • 通信周りの初期実装コストの削減 • URL やタイムアウト等を一括設定するだけで 通信基盤を整備可能 品質の標準化とメンテナンス性の向上 効果 17
18. 1. 自社のテンプレートについて 使用パッケージ (2024年6月時点) GoRouter • Flutter の Navigator 2.0 を使いやすくした Flutter 用の宣言型ルーティングパッケージ • URL パターンの定義、URL を使用したナビゲーション、 ディープリンクの処理などに対応 • 複雑な Deep Link の実装が容易になる • 画面を構築する際に URL という情報を加味することが前提となるため Web対応が容易になる 品質の標準化とメンテナンス性の向上 効果 18
19. 1. 自社のテンプレートについて 自動化周りについて (2024年6月時点) 初期化周り • プロジェクト名の自動設定 • 残りの手動設定手順のための issue を作成 pubspec.yaml 19
20. 1. 自社のテンプレートについて 自動化周りについて (2024年6月時点) PR作成時 • 変更されたパッケージを PR の label で表示する機能 • PR 作成後に自動的に Reviewer をランダムで割り当てる機能 20
21. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 21
22. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 check-actions • GitHub Actions の workflow file を 静的解析してくれるツール • 構文チェックだけでなく、秘匿情報の ハードコード検知などセキュリティリスク もあらかじめ検知可能 22
23. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 Static Analysis & Tests • Dart の静的解析やテストを走らせる • code formatting や circular dependencis の検知も行うので、 コードが安全かつ一貫性を保つことがで きる 23
24. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 custom-lint (Problem Matcher) • GitHub Actions で実行したログからエ ラー部分を正規表現で抽出する仕組み • エラーメッセージをアノテーションとして 表示する 24
25. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 diff-gen • build_runner を用いたコード生成時に 出力されるコードのハッシュ値が 一致するか確認する 25
26. 1. 自社のテンプレートについて 自動化周りについて PR チェック時 • markdownlint • 品 • 自 Markdown • Markdownlint を用いて静的解析 • コードと同様に構文やスタイルをチェッ クできる 26
27. 1. 自社のテンプレートについて まとめ パッケージ周り • 開発を迅速に始められ、一定の品質基準を保つことが可能 ◦ FVM を用いてプロジェクトのメンバー間の Flutter のバージョンを統一 ◦ Melos を用いて複数パッケージ管理と依存関係を管理 ◦ dio は HTTP 通信の初期実装コストを削減 自動化周り • プロジェクトの初期化、 PR 作成時、PR チェック時の3パターンについて用意 • PR チェック時は差分がある箇所のみチェックすることでリソースの無駄遣いを防ぐ アーキテクチャ • Feature-First で共通部分は cores として切り出した構造 • パッケージごとに依存関係が決められているので、循環依存などの問題は発生しにくい 27
28. アジェンダ 1. 自社のテンプレートについて 2. 実際に使って感じた 強みとツラミ 3. 今後の展望 4. まとめ 28
29. 2. 実際に使ったわかった強みとツラミ 概要 強み • ルーティングまわりで編集すべきファイルが多い (GoRouter 周り) • ログの設計を一からやる必要があった • ドメインに依存するコンポーネントの置き場所 • cores/core が肥大化する ツラミ • コマンド数発で環境が揃うので新たに参画しやすい • ファイルの置き場所に統一感が出る • アーキテクチャ的な余白を残していたため、プロジェクトごとに最適化しやすい • 技術選定 (Melos を使うかどうか)とかの話を飛ばすことができるので、 開発にスムーズに入ることができる 29
30. 3. 今後の展望 強み -アーキテクチャ的な余白による最適化 Feature-First との相性の悪さ • ドメインが明確な場合、 feature の適切な設定により並行開発が容易になるが、 開発当初から要件が流動的で feature の適切な設定が困難だった • 要件の先読みに失敗した場合、既存の feature でやりくりする際に feature 間の責務が曖昧になる恐れも 30
31. 3. 今後の展望 強み -アーキテクチャ的な余白 • features: UI に集中 ◦ Widget、状態、Notifier、Provider • cores_domain ◦ Model, Service, feature に閉じない状態 Repository など Features を UI に集中させることで Layer-First に近い構造に変更 • どこに何を配置するべきかの判断が容易に • 要件が変更され、デザインが大きく変更されたとしても影響 が features (UI) で収まりやすくなる • cores_domain のリソースを活用できるので プロトタイプを作りやすい 効果 feartures_yyy 31
32. 2. 実際に使ったわかった強みとツラミ ツラミ - ルーティングまわり 追加ファイル 32
33. 2. 実際に使ったわかった強みとツラミ ツラミ - ルーティングまわり 33
34. 2. 実際に使ったわかった強みとツラミ ツラミ - ルーティングまわり 追加ファイル Navigator の抽象クラスを features に書く Navigatorの実装クラスをappに書く TypedGoRoute を app に書く GoRouteData を apps/app に書く 必要があれば インポート 解決法 • 生成AI ◦ ある程度プロジェクトが 大きくなると規則性を把握する ◦ 初期は README とか実装する際 にやり方を詳しく書くと最初から うまくいく可能性はある 34
35. 2. 実際に使ったわかった強みとツラミ ツラミ - ログ設計 • 機能別・モジュール別の細かいログレベル制御 • 本番環境での部分的なログ送信 • そもそもテンプレになかった • パッケージ選定から 背景 • Talker と Crashlytics を用いて実現 ◦ dio との連携も容易 ◦ TalkerObserver でエラーログを Crashlytics に転送可能 解決法 解決できていないこと 35
36. 2. 実際に使ったわかった強みとツラミ ツラミ - ドメインに依存するコンポーネントの置き場所 • 画像表示する際に画像表示コンポーネントを 複数の feature で利用したいので画像モデルを domain にある Repository から直接取得したいが、、、 ◦ designsystem は domain に 直接依存できないので、コンポーネントに 直接モデルを引数として持たせられない ◦ designsystem と domain にモデル定義して feature ごとに取得・変換は冗長 背景 • domain と designsystem に依存する cores_ui の作成 ◦ 汎用コンポーネントと domain を組み合わせた 粒度の大きいものとし、 domain への直接依存を回避 ◦ ユーザー情報等 domain かつ異なる 複数の feature パッケージで使いまわす UI等 解決法 cores_ui 36 feartures_yyy
37. 2. 実際に使ったわかった強みとツラミ ツラミ - cores/core の肥大化 • core って何？ ◦ 「コア機能」の定義が曖昧で、 何を含めるべきかの判断が困難 ◦ 「共通機能」という名目で、 本来別の場所に配置すべき機能が混入 • 現在でも多様な機能（例外処理、拡張メソッド等）が混在 • 模索中 背景 解決法 37
38. 2. 実際に使ったわかった強みとツラミ まとめ ルーティングまわり ログ設計 ドメインに依存するコンポーネントの置き場所 cores/core の肥大化 • 追加 or 編集するファイルが多い • 生成AI はある程度規則性は把握するので、生成 AIを用いた実装時は問題にならない • Talker と Crashlytics を用いて実現 • 機能別・モジュール別の細かいログレベル制御やログの部分的な制御はまだ • designsystem は domain に直接依存できないので、共通の変換ロジックを持たせられない • 異なる複数の feature パッケージで使い回すための UI を提供する cores_ui を作成 • 「コア機能とは？」となり、何を含めるべきかの判断が困難 アーキテクチャの余白による最適化 • 当初から要件が流動的かつドメイン知識が発展途上だったので Layer-First に近い構造に変更 38
39. アジェンダ 1. 自社のテンプレートについて 2. 実際に使って感じた 強みとツラミ 3. 今後の展望 4. まとめ 39
40. 3. 今後の展望 概要 ✅ Flutter のバージョン管理を FVM から mise への移行 󰳕 アプリ内部の依存管理を Swift Package Manager, Melos 7 (Pub workspaces) への移行 ✅ ディレクトリ構造の整理・新アーキテクチャに移行 󰳕 デバッグ・ログ機能の充実化 現在の取り組み 40
41. 1. 自社のテンプレートについて FVM から mise への移行 mise • 開発環境構築・ツール管理・タスク実行を一つにまとめた CLI ツール • Dart を含め複数言語・ツールのバージョン管理を一元化できるのが特徴 • 公式の GitHub Actions があるので CI/CD での使い回しや環境統一が容易 • プロジェクトごとでツールのバージョンを揃えられる • Dart プロジェクトで Flutter 以外に必要となる 周辺ツールのセットアップが自動化可能 ◦ npm や linter、その他補助ツールも 導入・併用しやすくなる • GitHub Actions ではより本番に近い環境でテスト可能 スケーラビリティとメンテナンス性の向上 効果 mise.toml 41
42. 1. 自社のテンプレートについて FVM から mise への移行 脱 FVM したわけ • Dart を含め複数言語・ツールのバージョン管理を一元化したかったから • CSpell とか Bun とか等の npm から入れるパッケージを使いたかったから ◦ Markdownlint, yamllint, Firebase CLI 等も 42
43. 3. 今後の展望 Swift Package Manager, Melos 7 (Pub workspaces) への移行 • 管理するツールを減らしたい ◦ CocoaPods が Ruby 製 ◦ CocoaPodを持つことでRubyも管理する必要があるのでやめたい • CocoaPods がメンテナンスモードになった ◦ 新機能開発が停止し、長期的な保守運用に不安がある Swift Package Manager へ移行の理由 Melos 7 へ移行の理由 • Melos の機能を利用しつつ Pub workspaces によって依存関係の解決の時間を短縮したかったから • 脱 Melos が難しい ◦ 移行先が見つかっていない ▪ 自分たちでScriptファイル作成は可能だが管理が大変なので一旦移行を見送りたい 43
44. 3. 今後の展望 ディレクトリ構造の整理 • cores/core が何を表しているのかわからない ◦ 結局肥大化する • cores~ 廃止 ◦ より責務を細分化しパッケージとして分割 ◦ パッケージの肥大化の防止 44
45. 3. 今後の展望 新アーキテクチャ • Presentation Layer • Composition Root • Application Layer • Infrastructure Layer • Domain Layer Clean Architecture と Composition Root パターンの複合 45
46. 3. 今後の展望 新アーキテクチャ • Presentation Layer ◦ UI の表示と ユーザー操作の処理 • Composition Root ◦ アプリケーションの依存関係を 構成 ◦ 依存関係の注入を一箇所で管 理し、アプリケーションの構造を 明確にする役割 • Application Layer ◦ ユースケースの実装と アプリケーション固有の ビジネスロジック 46
47. 3. 今後の展望 新アーキテクチャ • Infrastructure Layer ◦ 外部システムとの連携と データの永続化 • Domain Layer ◦ ビジネスルールと ドメインロジックの実装 47
48. 3. 今後の展望 デバッグ・ログ機能の充実化 エラーハンドリング • Infrastructure Layer: Exception をキャッチして DomainException に変換して投げる • Application Layer: DomainException をキャッチして適切なデータに変換して返却する • UI でエラーハンドリングしない方針 Repository Usecase 48
49. 3. 今後の展望 デバッグ・ログ機能の充実化 エラーハンドリング • Infrastructure Layer: Exception をキャッチして DomainException に変換して投げる • Application Layer: DomainException をキャッチして適切なデータに変換して返却する • UI でエラーハンドリングしない方針 Widget (UI) 49
50. 3. 今後の展望 デバッグ・ログ機能の充実化 ログ出力 • Talker のロガーを使う予定 ◦ ログの具体的な実装を追加する場合は Observer で設定できるようにする予定 • ログの使用するツールはプロジェクトごとに検討し、 ローカルで出力するもののみ残す予定 ◦ Crashlytics ◦ Datadog 50
51. 3. 今後の展望 まとめ Swift Pkg Manager, Melos 7 (Pub workspaces) への移行 ディレクトリ構造の改善・新アーキテクチャに移行 デバッグ・ログ機能の充実化 • SPM : 管理するツールを減らしたい & CocoaPods がメンテナンスモードになったので移行 • Melos 7 : Melos の機能を利用しつつ Pub workspaces による依存関係の解決の時間の短縮のため移行 • cores/core が何を表しているのかわからないので廃止 • 細分化された責務分割によりパッケージの肥大化の防止 • Clean Architecture と Composition Root パターンの複合 • 各レイヤーでエラーハンドリングを策定 • ログのツールはプロジェクトごとに検討したほうが良いのでローカル出力のみ実装予定 51
52. 今回の発表をするにあたりチームメンバーが協力してくれました！ 🎉 52
53. アジェンダ 1. 自社のテンプレートについて 2. 実際に使って感じた 強みとツラミ 3. 今後の展望 4. まとめ 53
54. 4. まとめ まとめ 自社のテンプレートについて • 一定の品質基準を保ちつつ開発を迅速に開始するための中・大規模向け標準テンプレート 今後の展望 • アーキテクチャやデフォルトのパッケージ構造を Layer-First に変更完了 • ログ基盤の整備やパッケージの依存管理周りの改善中 実際に使って感じた強みとツラミ • アーキテクチャの余白によって最適化はしやすいものの、 ログの設計の必要があったり、ファイルの配置に迷いが生じたりする • ルーティング設定時に編集が必要なファイルが多い 54
55. ご清聴ありがとうございました 55