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

by akkiee76

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

potatotips #79 会社紹介株式会社ラクス「ITサービスで企業の成長を継続的に支援します」をミッションに、お客様の課題解決やビジネスの成長をを継続的に支援するクラウドサービスを提供しています。

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

potatotips #79 背景他にも・　Cordova 自体の EOL （セキュリティリスク）・　Cordova 開発者減少といった採用面での課題といった背景もあり、 Cordova から Kotlin へリプレースすることに

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

potatotips #79 アーキテクチャ選定にあたって① 以下の観点から、MVVM アーキテクチャを採用・　Android 公式アーキテクチャ・　モダンアーキテクチャは、技術的に難しい * MVVM アーキテクチャイメージ

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

potatotips #79 2. Package 構成

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

potatotips #79 実践してイマイチだったこと ● メンバーによってアーキテクチャの理解度がバラけた ○ 事前の学習コスト（準備コスト）がやや不十分だった ● ライブラリ選定がややモダンだった ○ AndroidX を中心としたライブラリの学習コストが不十分だった

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

potatotips #79 技術的課題イメージ NetworkError は Presentation Layer に配置されているが、・ Data Layer から throw ・ Presentation Layer で catch されるため各層から参照されることに。このように層を跨いで参照されるクラスが存在している。

Slide 20

Slide 20 text

potatotips #79 技術的課題へのアプローチ Before After ● マルチプロジェクトを採用し、抽象クラスはコアドメインに移行 ● 技術駆動パッケージングからドメイン駆動パッケージングに移行

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

potatotips #79 ご静聴ありがとうございました