Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アプリアーキテクチャを明文化しチームの開発効率をアップ
Search
akkiee76
October 04, 2022
Technology
1
1.5k
アプリアーキテクチャを明文化しチームの開発効率をアップ
akkiee76
October 04, 2022
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Meet the Translation API
akkie76
0
220
コードレビューで開発を加速させるAIコードレビュー
akkie76
1
320
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
2.5k
コードレビューを支援するAI技術の応用
akkie76
5
680
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
7.6k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
470
Observationではじめる値監視
akkie76
4
4.4k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
500
rememberUpdatedState の使いどころを考える
akkie76
0
350
Other Decks in Technology
See All in Technology
【shownet.conf_】ShowNet 2024 ~ Inter * Network ~
shownet
PRO
0
390
All your memory are belong to… whom?
ennael
PRO
0
550
Strict Concurrencyにしたらdeinitでクラッシュする話
0si43
0
120
普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
ytaka23
3
550
Semantic Kernel の Agent 機能試してみた!
okazuki
1
100
LeSSはスクラムではない!?LeSSにおけるスクラムマスターの振る舞い方とは / Scrum Master Behavior in LeSS
toma_sm
0
130
ORM と向き合う
hoto17296
8
6k
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
2
200
小さな勉強会の始め方、広げ方、あるいは友達の作り方 / How to Start, Grow, and Build Connections with Small Study Groups
ar_tama
2
1.2k
スモールスタート、不都合な真実 〜 耳当たりの良い言葉に現場が振り回されないために/20240930-ssmjp-small-start
opelab
13
1.7k
Assisted reorganization of data structures
ennael
PRO
0
220
【shownet.conf_】ShowNet伝送改めShowNet APN 2024
shownet
PRO
0
330
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
94
5.1k
Testing 201, or: Great Expectations
jmmastey
38
7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.9k
A designer walks into a library…
pauljervisheath
201
24k
VelocityConf: Rendering Performance Case Studies
addyosmani
324
23k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
42
6.5k
Done Done
chrislema
181
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9k
Gamification - CAS2011
davidbonilla
80
5k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
249
21k
Adopting Sorbet at Scale
ufuk
73
8.9k
Transcript
#RAKUSMeetup ©2022 RAKUS Co., Ltd. アプリアーキテクチャを明文化して チームの開発効率をアップ Android アーキテクチャを 明文化して臨んだ新規開発を振り返る
@akkiee76
#RAKUSMeetup 自己紹介 Akihiko Sato / 株式会社ラクス Lead Engineer / @akkiee76
SaaS 開発 (Backend, Frontend) / Mobile 開発 (iOS, Android) 上流工程、コードレビュー、チームの課題改善など 読書 / コーヒー / HHKB / 腹筋ローラー・体幹トレーニング
#RAKUSMeetup 今日伝えたいこと アーキテクチャを明文化して 得られたことと今後に向けての課題
#RAKUSMeetup 背景 楽楽精算では、現在 Kotlin 版と Cordova 版の 2つの Android アプリをリリースしています。
これまで Kotlin 版では、最新の Android バージョンに追従してき ましたが、Cordova 版では FW の対応の遅れにより、 タイムリーな対応が難しい状況でした。
#RAKUSMeetup 背景 他にも ・ セキュリティリスクの懸念 ・ Cordova 開発者減少といった採用面での課題 といった背景もあり、 Cordova から Kotlin
へリプレースすることに
#RAKUSMeetup Android チームの現状 現在のチームは、 ・ Android 開発のナレッジが少ない ・ 新規アプリの開発経験がない という課題があり、 新規案件開発の苦戦は目に見えていました。
#RAKUSMeetup 現状へのアクション そこで、開発の推進を目的としたアクションとして アーキテクチャを選定し、明文化することにしました。
#RAKUSMeetup アーキテクチャ選定にあたって① アーキテクチャ選定の観点として ・ Android 公式アーキテクチャ ・ モダンアーキテクチャは技術的に扱えない可能性 オーソドックスな MVVM アーキテクチャを採用することに。
#RAKUSMeetup アーキテクチャ選定にあたって② MVVM アーキテクチャは 2017 年位から RxJava を中核に DataBinding アーキテクチャとして広まったアーキテクチャです。
Jetpack Compose などの今後の展望を考えると、 Android 標準アーキテクチャである MVVM アーキテクチャは、 今後も運用しやすいアーキテクチャであると考えました。
#RAKUSMeetup アーキテクチャ選定にあたって③ また、アーキテクチャを検討する上で ・ 関心の分離を重要原則とする ・ クラスの責務をできるだけシンプル/コンパクトに保つ ・ 各クラスのテストの容易性を向上させること を大方針とすることに。
#RAKUSMeetup ここからは 実際に明文化した内容を紹介します。
#RAKUSMeetup 1. アプリケーションレイヤー構成 基本的なレイヤー構成として、 3層レイヤー構成を採用。 ・ Presentation Layer ・ Domain
Layer ・ Data Layer それぞれを役割を定義します。
#RAKUSMeetup Presentation Layer(プレゼンテーション層) プレゼンテーション層は、ユーザーに情報を表示し、入力を受け付ける機能を 持っています。具体的には、ユーザー操作や外部入力(レスポンス)によってデー タが変更されるたびに、変更された情報を反映するよう UI を更新する必要が あります。 主にプレゼンテーション層は、Activity、Fragment、ViewModel
や BindingModel に変換するための Converter などを配置します。また、 RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼン テーション層に配置します。
#RAKUSMeetup Domain Layer(ドメイン層) ドメイン層は、複雑なビジネスロジックや複数の ViewModel で再利用される 単純なビジネスロジックが隠蔽(カプセル化)されたレイヤーです。 ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の ロジックをこのレイヤーに実装します。また、各ユースケースでは異なるビジネス ロジックが集約されるため、それぞれのユースケースクラスは疎であることが
アーキテクチャとして重要です。
#RAKUSMeetup Data Layer(データ層) データ層は、アプリで扱うデータに関連するロジックが集約されます。具体的に は、アプリで使用するデータの作成、保存、変更方法(APIに関するものを含む) を決定する実際のロジックで構成されることがこのレイヤーの期待です。 データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジト リで構成されます。また、アプリで処理するデータの種類ごとに
Repository を作成する必要があります。
#RAKUSMeetup 2. Package 構成
#RAKUSMeetup 3. 基本クラスに各ルールを明文化 ・Activity ・Fragment ・ViewModel ・UseCase ・Repository ・責務 ・命名規則
・ルール(制約) ・実装例 ・テストで確認すること ・テスト実装例 明文化 明文化した各ルールを適用したサンプルプロジェクトも用意
#RAKUSMeetup 2ヶ月程度で開発完了 振り返ってみると・・・
#RAKUSMeetup 実践してよかったこと 1. チームの技術力が向上 ・ オブジェクト指向の成長 2. 設計の議論をすることが少なく、開発に注力できた ・ チームの生産性が高まった (見積に対しての実績) 3.
クラスの責務を小さくしたため、テストが描きやすかった ・ テスト品質の担保
#RAKUSMeetup 実践してイマイチだったこと 1. メンバーによって理解度がバラけた ・ 事前の学習コスト(準備コスト)がやや不十分だった 2. ライブラリ選定がややモダンだった ・ 新しいライブラリ・フレームワークを利用する実装コスト
#RAKUSMeetup 技術的課題 技術駆動パッケージング* による参照関係 ・ 横断的に利用されるクラス・コンポーネントの配置 ・ package private を維持できない * 設計パターンによるフォルダ分け
#RAKUSMeetup 技術的課題イメージ NetworkErrorはPresentation Layerに配置されているが、 通信時にcatchされ、Fragment(View)でダイアログ表示のため、 各層から参照されてしまっている。 このように層を跨いで参照されて いるクラスが存在してしまった。
#RAKUSMeetup 技術的課題へのアプローチ 1. TOPレベルでの各層に分けるパッケージングをやめ、ドメインを ベースとしたパッケージング構成に変更する 2. どの層からも参照される抽象的なクラスは、 マルチプロジェクト構成にして アプリケーションから参照させる 機能拡張に伴い、更なる問題も・・・
#RAKUSMeetup 技術的課題へのアプローチ Before After
#RAKUSMeetup まとめ アーキテクチャを明文化すると、 1. チームの技術力の向上 2. 開発の生産性向上 3. 品質向上 といった恩恵を受けることができます。
#RAKUSMeetup まとめ また、開発中に発生する技術的負債を解決することで、 よりチームの技術力の向上に繋がります! チームでトライしてみてはいかがでしょうか。
#RAKUSMeetup ご静聴ありがとうございました