Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アプリアーキテクチャを明文化しチームの開発効率をアップ

akkie76
October 04, 2022

 アプリアーキテクチャを明文化しチームの開発効率をアップ

akkie76

October 04, 2022
Tweet

More Decks by akkie76

Other Decks in Technology

Transcript

  1. #RAKUSMeetup
    ©2022 RAKUS Co., Ltd.
    アプリアーキテクチャを明文化して
    チームの開発効率をアップ
    Android アーキテクチャを
    明文化して臨んだ新規開発を振り返る
    @akkiee76

    View full-size slide

  2. #RAKUSMeetup
    自己紹介
    Akihiko Sato / 株式会社ラクス Lead Engineer / @akkiee76
    SaaS 開発 (Backend, Frontend) / Mobile 開発 (iOS, Android)
    上流工程、コードレビュー、チームの課題改善など
    読書 / コーヒー / HHKB / 腹筋ローラー・体幹トレーニング

    View full-size slide

  3. #RAKUSMeetup
    今日伝えたいこと
    アーキテクチャを明文化して
    得られたことと今後に向けての課題

    View full-size slide

  4. #RAKUSMeetup
    背景
    楽楽精算では、現在 Kotlin 版と Cordova 版の
    2つの Android アプリをリリースしています。
    これまで Kotlin 版では、最新の Android バージョンに追従してき
    ましたが、Cordova 版では FW の対応の遅れにより、
    タイムリーな対応が難しい状況でした。

    View full-size slide

  5. #RAKUSMeetup
    背景
    他にも
    ・ セキュリティリスクの懸念
    ・ Cordova 開発者減少といった採用面での課題
    といった背景もあり、
    Cordova から Kotlin へリプレースすることに

    View full-size slide

  6. #RAKUSMeetup
    Android チームの現状
    現在のチームは、
    ・ Android 開発のナレッジが少ない
      ・ 新規アプリの開発経験がない
    という課題があり、
    新規案件開発の苦戦は目に見えていました。

    View full-size slide

  7. #RAKUSMeetup
    現状へのアクション
    そこで、開発の推進を目的としたアクションとして
    アーキテクチャを選定し、明文化することにしました。

    View full-size slide

  8. #RAKUSMeetup
    アーキテクチャ選定にあたって①
    アーキテクチャ選定の観点として
    ・ Android 公式アーキテクチャ
    ・ モダンアーキテクチャは技術的に扱えない可能性
    オーソドックスな MVVM アーキテクチャを採用することに。

    View full-size slide

  9. #RAKUSMeetup
    アーキテクチャ選定にあたって②
    MVVM アーキテクチャは 2017 年位から RxJava を中核に
    DataBinding アーキテクチャとして広まったアーキテクチャです。
    Jetpack Compose などの今後の展望を考えると、
    Android 標準アーキテクチャである MVVM アーキテクチャは、
    今後も運用しやすいアーキテクチャであると考えました。

    View full-size slide

  10. #RAKUSMeetup
    アーキテクチャ選定にあたって③
    また、アーキテクチャを検討する上で
    ・ 関心の分離を重要原則とする
    ・ クラスの責務をできるだけシンプル/コンパクトに保つ
    ・ 各クラスのテストの容易性を向上させること
    を大方針とすることに。

    View full-size slide

  11. #RAKUSMeetup
    ここからは
    実際に明文化した内容を紹介します。

    View full-size slide

  12. #RAKUSMeetup
    1. アプリケーションレイヤー構成
    基本的なレイヤー構成として、
    3層レイヤー構成を採用。
     ・ Presentation Layer
     ・ Domain Layer
     ・ Data Layer
    それぞれを役割を定義します。

    View full-size slide

  13. #RAKUSMeetup
    Presentation Layer(プレゼンテーション層)
    プレゼンテーション層は、ユーザーに情報を表示し、入力を受け付ける機能を
    持っています。具体的には、ユーザー操作や外部入力(レスポンス)によってデー
    タが変更されるたびに、変更された情報を反映するよう UI を更新する必要が
    あります。
    主にプレゼンテーション層は、Activity、Fragment、ViewModel や
    BindingModel に変換するための Converter などを配置します。また、
    RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼン
    テーション層に配置します。

    View full-size slide

  14. #RAKUSMeetup
    Domain Layer(ドメイン層)
    ドメイン層は、複雑なビジネスロジックや複数の ViewModel で再利用される
    単純なビジネスロジックが隠蔽(カプセル化)されたレイヤーです。
    ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の
    ロジックをこのレイヤーに実装します。また、各ユースケースでは異なるビジネス
    ロジックが集約されるため、それぞれのユースケースクラスは疎であることが
    アーキテクチャとして重要です。

    View full-size slide

  15. #RAKUSMeetup
    Data Layer(データ層)
    データ層は、アプリで扱うデータに関連するロジックが集約されます。具体的に
    は、アプリで使用するデータの作成、保存、変更方法(APIに関するものを含む)
    を決定する実際のロジックで構成されることがこのレイヤーの期待です。
    データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジト
    リで構成されます。また、アプリで処理するデータの種類ごとに Repository
    を作成する必要があります。

    View full-size slide

  16. #RAKUSMeetup
    2. Package 構成

    View full-size slide

  17. #RAKUSMeetup
    3. 基本クラスに各ルールを明文化
    ・Activity
    ・Fragment
    ・ViewModel
    ・UseCase
    ・Repository
    ・責務
    ・命名規則
    ・ルール(制約)
    ・実装例
    ・テストで確認すること
    ・テスト実装例
    明文化
    明文化した各ルールを適用したサンプルプロジェクトも用意

    View full-size slide

  18. #RAKUSMeetup
    2ヶ月程度で開発完了
    振り返ってみると・・・

    View full-size slide

  19. #RAKUSMeetup
    実践してよかったこと
    1. チームの技術力が向上
      ・ オブジェクト指向の成長
    2. 設計の議論をすることが少なく、開発に注力できた
      ・ チームの生産性が高まった (見積に対しての実績)
    3. クラスの責務を小さくしたため、テストが描きやすかった
      ・ テスト品質の担保

    View full-size slide

  20. #RAKUSMeetup
    実践してイマイチだったこと
    1. メンバーによって理解度がバラけた
    ・ 事前の学習コスト(準備コスト)がやや不十分だった
    2. ライブラリ選定がややモダンだった
    ・ 新しいライブラリ・フレームワークを利用する実装コスト

    View full-size slide

  21. #RAKUSMeetup
    技術的課題
    技術駆動パッケージング* による参照関係
      ・ 横断的に利用されるクラス・コンポーネントの配置
      ・ package private を維持できない
    * 設計パターンによるフォルダ分け

    View full-size slide

  22. #RAKUSMeetup
    技術的課題イメージ
    NetworkErrorはPresentation Layerに配置されているが、
    通信時にcatchされ、Fragment(View)でダイアログ表示のため、
    各層から参照されてしまっている。
    このように層を跨いで参照されて
    いるクラスが存在してしまった。

    View full-size slide

  23. #RAKUSMeetup
    技術的課題へのアプローチ
    1. TOPレベルでの各層に分けるパッケージングをやめ、ドメインを
    ベースとしたパッケージング構成に変更する
    2. どの層からも参照される抽象的なクラスは、
    マルチプロジェクト構成にして
    アプリケーションから参照させる
    機能拡張に伴い、更なる問題も・・・

    View full-size slide

  24. #RAKUSMeetup
    技術的課題へのアプローチ
    Before After

    View full-size slide

  25. #RAKUSMeetup
    まとめ
    アーキテクチャを明文化すると、
    1. チームの技術力の向上
    2. 開発の生産性向上
    3. 品質向上
    といった恩恵を受けることができます。

    View full-size slide

  26. #RAKUSMeetup
    まとめ
    また、開発中に発生する技術的負債を解決することで、
    よりチームの技術力の向上に繋がります!
    チームでトライしてみてはいかがでしょうか。

    View full-size slide

  27. #RAKUSMeetup
    ご静聴ありがとうございました

    View full-size slide