アプリアーキテクチャ概論

2019.10.11(FRI) 新潟最大級のモバイルアプリカンファレンス MOBILE CREW NIIGATAでの講演資料です。

アプリ開発はプロダクトのステージや体制など外的要因からも影響を受けています。 本講演ではAndroidアプリをテーマに変化に強いアーキテクチャや構成の選択的アプローチを紹介し、 プロダクトにおいてソフトウェア開発者ができる貢献、アーキテクチャの価値を示します。

カンファレンス概要：https://www.mobilecrew.jp/
【こんな人にオススメ！】
・現在モバイルアプリ開発に携わっている技術者及びデザイナー・その他関連職
・モバイルアプリ開発に興味があるが、情報のキャッチアップの場に困っている
・これからモバイルアプリ開発者を目指す学生

Transcript

1. アプリ アーキテクチャ概論 @mhidaka 1 ソフトウェア開発におけるアーキテクチャの価値 ηογϣϯ !NIJEBLB ΞϓϦΞʔΩςΫνϟ֓࿦
2. アプリ アーキテクチャ概論 @mhidaka 2 ソフトウェア開発におけるアーキテクチャの価値
3. @mhidaka 日高 正博 3
6. 今日の概要 Main points of my session 6
7. 今日、伝えたいこと 7 ・アプリ開発に影響する外的要因 ・Androidアプリにおけるアーキテクチャ選択 ・進化するスタンダードへの追従 ・価値創出の中心になろう
8. はじめに Introduction : background of an application architecture. 8
9. 9 CC-BY-SA https://www.flickr.com/photos/arturstaszewski/7048604301/ プロダクトへの貢献
10. プロダクトへの貢献 10 開発者は、どのようなかたちの貢献ができるか プロダクト ソフトウェア開発者
11. プロダクトへの貢献 11 ソフトウェア技術で開発速度に寄与すること。とくにエンジニアの生産 性は現代アプリ開発の大きな課題。スピードは価値へと直結 プロダクト ソフトウェア開発者 生産性の向上
12. アプリケーション開発での生産性 12 生産性を向上させるには？ ソフトウェア技術以外の要素のほうが実は影響が大きい チーム 生産性 スキルセット 仕様 ドメイン知識 品質 プラット フォーム 納期 ビジネス 経験 言語 設計 アーキテクチャ
13. 技術的背景 プロダクトとソフトウェアのかかわり 13 技術的背景のもと、アーキテクチャが選択される 完全に自由に選べるものではなく、プロダクトごとマッチする選択肢が異なる プラットフォーム アーキテクチャ プログラミング言語 ライブラリ
14. memo 14 エンジニア/チームの生産性が鍵 アーキテクチャは原動力 組織やドメインが強く影響
15. 本講演の主眼 15 生産性を最大化するアプローチと、障壁となる課題について ソフトウェアの複雑性を下げるためアーキテクチャを使おう （難しくないというわけではない。課題を整理し、前に進むた めのもの）Androidアプリ開発でのアーキテクチャが何を解決し ようとしているのか、ソフトウェア開発の視点で解説します
16. アプリ開発に影響する外的要因 The first step is always the hardest. 16
17. 背景にある要素 ソフトウェアと組織 17 アーキテクチャ選定に掛かる前にアプリ設計は前述のとおり、さま ざまな要因に依存している。とくに組織、ドメインとは密接 アーキテクチャ 組織構造 ドメイン領域 技術選択 プロダクト の前進
18. テクノロジーによる貢献 18 アーキテクチャは勝手には定まらない。ソフトウェアで解決するべき課題が存在する アプリ開発者の貢献 生産性を最大化する意思 思想をソフトウェアに反映 アーキテクチャ・開発手法の選択
19. 開発のボトルネックはなにか 19 内的・外的要因のもつライフサイクルの違いが複雑化を呼び おこし、生産性低下の一因になる チームに所属しているエンジニアの異動・スキルセットの濃淡 要件の変更、納期の流動性、継続開発による過去資産の継承 プラットフォーム、ライブラリのバージョン更新への対応
20. 20 CC-BY-SA https://www.flickr.com/photos/saverio_domanico/11197540475 アーキテクチャの役割
21. Androidアプリ開発における アーキテクチャ選択 The first step is always the hardest. 22
22. 基本的なアーキテクチャ構成:MVVM 23 https://material.io/develop/android/ Fragment ViewModel Repository Data Source
23. これまでのアーキテクチャ選定の歴史 24 無法地帯→アーキテクチャの浸透→モデル・ドメイン分離の発達 God Activity Resources Leek Device Diff Version Diff Lifecycle MVVM AAC Data Bindings MV-*
24. 基本的なアーキテクチャ構成 25 Viewへの変更はデータバインディングを経由する。ViewModel がドメイン領域と表示を分離する役割
25. ViewModelはAndroid独特の実装も吸収 26 class PostDetailViewModel(...) : ViewModel() { var commentIds: MutableLiveData<List<Comment>> = MutableLiveData() fun showComments() { viewModelScope.launch { val thread = chatRepository.getChatThread(postId) if(thread.success) { commentIds.postValue(thread.comments) } } } override fun onCleared() { super.onCleared() // 後処理 } } Fragument ViewModel Repository Database
26. 問題の分割 27 Data Source Repository ViewModel State Operations UI / View Activity Fragment 複雑なアプリケーション構成要素を分解する役割がアーキテクチャ。Android Specific / ResourcesをViewに閉じ込める
27. チームとアーキテクチャ 28 基本的には巨人の肩にのる戦略がコストパフォーマンスがよ い。しかしチーム（組織・技術背景）に依存する要因は残る。 スキルセット チーム構成 既存ライブラリ
28. チームとアーキテクチャ 29 よく開発で議論にあがる課題はDI、RxJavaのような技術要素 の習得コストや利用によるアプリ肥大化、OSバージョンアッ プの負荷など継続的かつ生産性の高い開発体制作り スキルセット チーム構成 既存ライブラリ
29. 大規模開発とアーキテクチャ 30 CC-BY-SA https://www.flickr.com/photos/4nitsirk/6451156409
30. 大規模開発とアーキテクチャ 31 どうしても…生産性は…おちるんですよ！ 長期に渡って利用され、豊かなドメインを持ち、大規模たる組 織構造に支えられている。
31. 大規模開発とアーキテクチャ 32 Flux、Reduxといったデータフローを単方向に整えるアーキテ クチャの利用、モジュライズを発達させたアプローチが一般的。
32. Androidアプリのミッシングリング 33 現代的なアプリ開発に適した0→1フェーズが素早く、10や100 に成長できるスケーラブルな設計手法は見つかっていない ・スケーラビリティがほどよく維持されて ・継続的に開発しやすく ・複雑性が増加しにくい
33. 進化するスタンダードへの追従 The first step is always the hardest. 34
34. 解決への取組：Android Jetpack 35 Googleによるライブラリ集。プ ラットフォームのAPIから独立し、 互換性の維持やボイラープレート の排除、Androidアプリのベスト プラクティスを提供。Play Service API機能の統合も https://developer.android.com/jetpack?hl=ja
35. Androidの分断をライブラリで吸収 36 プラットフォームが提供するAPIはよりソリッドかつ中間表現 にちかい命令的なものへ変化。ライブラリの役割が増加 ドメインなど 重要な要素へ集中 アプリケーション 表示やプラットフォーム依存 Android Specific AppCompat, LifeCycle, Camera
36. エコシステムの変化を生み出す 37 互換性維持やライフサイクル管理もライブラリが隠蔽してくれ るように。単機能提供にとどまらない プラットフォーム アーキテクチャ プログラミング言語 ライブラリの役割が拡大
37. 38 CC-BY-SA https://www.flickr.com/photos/46999807@N03/4644884138/ Jetpack Compose
38. より良いアーキテクチャへの挑戦 39 https://developers-jp.googleblog.com/2019/06/whats-new-with-android-jetpack.html Jetpack Compose 新しいUI Toolkit ライブラリ
39. 新しいアーキテクチャへの取り組み 40 Jetpack Composeがある場合の解決できる課題 Kotlinで書ける 変化を観測 自動で更新 再利用性の高さ 状態管理 XML不要のシンプルさ 宣言的UI 独立性 ボイラープレートの排除
40. memo 41 Jetpack Composeはpre-α ・まだまだ開発中 ・既存資産が利用できない ・学習コスト
41. 設計のギャップをなくす 42 アプリの規模拡大の衝撃を緩和するアーキテクチャへの進化 MVVM → Redux、Flux…からリアクティブプログラミングへのシフト
42. memo 43 アーキテクチャの注意 ・アプリの成長に対応する ・背景が変わることがある ・複雑性の増加を抑え、生産性 を高める運用が不可欠
43. 価値創出の中心になろう Flavor text abcdefg abcdefg abcdefg abcdefg abcdefg abcdefg 44
44. アプリケーション開発での生産性 45 ソフトウェア技術でプロダクトの価値向上に寄与すること。 生産性は現代アプリ開発の大きな課題 チーム 生産性 スキルセット 仕様 ドメイン知識 品質 言語 アーキテクチャ プラット フォーム 納期 設計 ビジネス 経験
45. ジャンプ台を作らない 46 ・技術的な変化は随時取り入れていくことが大事 停滞すると最新のものとの乖離が進み、追従が困難に ダメなら戻せるのがソフトウェアの強み CC-BY-SA https://www.flickr.com/photos/plastique/6249087375
46. アーキテクチャを理解する 47 ・取り組んでいる課題について議論する ・今あるアーキテクチャに従うだけではなく理解と活用を。 ・生産性向上のレシピを探して試してみる CC-BY-SA https://www.flickr.com/photos/plastique/6249087375
47. アーキテクチャの選定 48 開発の背景に合わせて最適な選択が異なる • エコシステムに支えられている部分が多いため、標準的手法 であれば失敗は少ない（バグも減る！） • 導入だけでなくプロダクトとの二人三脚で更新するもの • 将来的にはリアクティブプログラミングのパラダイムがくる
48. 最新技術が集まるカンファレンス 49
49. Thank You! mhidaka@droidkaigi.jp 50