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
June 22, 2022
Technology
0
800
アーキテクチャを明文化して開発に臨んだ話
akkiee76
June 22, 2022
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Meet the Translation API
akkie76
0
150
コードレビューで開発を加速させるAIコードレビュー
akkie76
0
160
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
1.2k
コードレビューを支援するAI技術の応用
akkie76
5
590
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
7.1k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
320
Observationではじめる値監視
akkie76
3
3.3k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
420
rememberUpdatedState の使いどころを考える
akkie76
0
280
Other Decks in Technology
See All in Technology
AutomatedLabを使って内部ペンテストを勉強しよう! -やられ社内ネットワークの自動構築-
n_etupirka
1
610
[2024最新版]AWS Control Towerを使ったセキュアなマルチアカウント環境の作り方
hiashisan
0
270
スレットハンティングについて知っておきたいこと
hacket
0
130
[NIKKEI Tech Talk] KDDI/KAG Scrum & Community for Engineering Training
curanosuke
2
220
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
0
190
MySQLのロックの種類とその競合
yoku0825
6
1.6k
AWSでRAGを作る法方
sonoda_mj
1
140
Matterport を使ってクラスメソッド各拠点のバーチャルオフィスツアーを作成してみた
wakatsuki
0
160
データ分析基盤を作ってみよう~設計編~
nrinetcom
PRO
1
110
DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-
jun2882
0
210
地理情報とAPIのトレンド
nagix
0
160
公共領域から学ぶ クラウド移行についてエンジニアが意識していること
kawakawa2222
0
140
Featured
See All Featured
Practical Orchestrator
shlominoach
185
10k
4 Signs Your Business is Dying
shpigford
178
21k
Atom: Resistance is Futile
akmur
261
25k
Agile that works and the tools we love
rasmusluckow
325
20k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
277
13k
Visualization
eitanlees
139
14k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
17
1.5k
Bash Introduction
62gerente
607
210k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
325
21k
What's new in Ruby 2.0
geeforr
338
31k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
129
32k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
36
9.1k
Transcript
〜 Architecture を事前準備して臨んだ開発を振り返る 〜 Android Architecture を明文化して 新規開発に臨んだ話 Akihiko Sato
#78 iOS / Android 開発 Tips 共有会
自己紹介 佐藤 晶彦 株式会社ラクス 楽楽精算開発 モバイル開発 / Lead Engineer SaaS
(Backend, Frontend) / Mobile (iOS, Android) 主な業務は、設計 〜 受入、チームの課題改善など 最近のマイブームは、縄跳びトレーニング
今日伝えたいこと 開発開始前に Architecture を明文化して 良かったこと & 課題となったこと
背景 弊社では、 Native (Kotlin) 版と Cordova 版の 2 つの Android
アプリをリリースしています。 昨年 Native 版では Android 12 対応などを進めて来ましたが、 Cordova 版では FW のリリースと開発期間が合わないこともあり、 タイムリーな対応ができない状況でした。
背景 2 また、今後 Cordova 自体の開発が終了して EOL となった場合、 セキュリティリスクが生じる可能性も。。。
背景 3 他にも、市場に Cordova 開発者が少なくなっており、 採用面においてもなかなか厳しい状況でした・・・。 心機一転 Native 版に作り替えることになりました!
Android チームの現状 しかしながら、 Android チームは若手が中心で、 開発の苦戦は目に見えていたため、 事前に基本的方針として Architecture を定めることしました。
Architecture 選定にあたって 基本型として MVVM Architecture を採用することにしました。 まず Architecture を選定するにあたり ・
Android の公式 Architecture である ・モダンな Architecture を扱える技術力あるチームではない
Architecture 選定にあたって MVVM Architecture は 2017~8 年位から RxJava を主軸に 台頭した
Architecture ですが、 Jetpack Compose の進化と今後の展望を考えると、 Android の標準 Architecure として MVVM Architecture は 今後も Architecture として運用しやすいと考えました。
Architecture 選定にあたって 加えて Architecture 検討する上で関心の分離を重要な原則とし、 クラスの責務をできるだけシンプルに保つことで、 ライフサイクルに関連する多くの問題を回避し、 クラスごとのテストの容易性を向上させることにしました。
3 層レイヤー構造による構成 基本的なレイヤー構造として、 ・プレゼンテーションレイヤー ・ドメインレイヤー ・データレイヤー 3 層 MVVM Architecture
構成を採用
プレゼンテーション層( Presentation Layer ) プレゼンテーション層からユーザーに情報を表示し、入力を受け付ける機能を 持っています。具体的には、または外部入力によってデータが変更されるたび に、変更された情報を反映するよう UI を更新する必要があります。 主にプレゼンテーション層は、
Activity, Fragment, ViewModel や BindingModel に変換するための Converter を配置します。また、 RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼンテーション層に配置しま す。
ドメイン層( Domain Layer ) 複雑なビジネスロジックや複数の ViewModel で再利用される単純なビジネスロ ジックが隠蔽(カプセル化)されたレイヤーです。 ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の ロジックをこのレイヤーに実装します。
また、各ユースケースでは異なるビジネスロジックが集約されるため、それぞれ のユースケースクラスは疎であることがアーキテクチャとして重要です。
データ層( Data Layer ) データ層は、アプリで扱うデータに関連するロジックが集約されます。 具体的には、アプリで使用するデータの作成、保存、変更方法( API に関するも のを含む)を決定する実際のロジックで構成されることがこのレイヤーの期待で す。
データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジトリ で構成されます。また、アプリで処理するデータの種類ごとに Repository を作成 する必要があります。
Package 構成を明示
基本クラスのルールも明文化 ・ Activity ・ Fragment ・ ViewModel ・ UseCase ・
Repository ・ DI Module ・責務 ・命名規則 ・ルール(制約) ・実装例 ・テストで確認すること ・テスト実装例 明文化 ルールを明文化して、サンプルプロジェクトも用意
開発を進めて感じたこと ・チームの基本的技術力が向上 ・開発中に基本的なアーキテクチャの議論することがない 👉 開発に集中できる 👉 チームの生産性が高まった ・責務によりクラスを小さく分けたためテストが書きやすかった 👉 テスト品質の担保
課題に感じたこと ・ Package 構造 👉 技術駆動パッケージングよる参照関係 👉 レイヤー横断的な component をどう扱うか
・各レイヤーごとのによる依存性 👉 依存関係逆転原則を活用できていない 今後改善予定
まとめ Architecture を明文化すると 👉 チームの基本技術の向上 👉 チームの生産性の向上 👉 品質の向上 といった恩恵を受けることができるので、
皆様のチームでもトライしてみてはいかがでしょうか。
オンラインイベントや中途採用を積極的に行ってます! 最後に
ご清聴ありがとうございました