Bonfire Android #3 に参加しました
遅くなってごめんなさい.完全に私の怠慢です.
なんかそれ,発表のときに伝えたかったニュアンスとズレてる🤔🤔🤔というときは 指摘していただけると助かります.
はじめに
3/12に参加してきました.
今回のテーマは サービスと設計 という,話を聞いているとだんだん耳が痛くなって途中退出したくなる系(?)だけどめちゃくちゃためになる話でした.
Androidアプリにおけるソフトウェア設計の考え方
スライド
ざっくりまとめ
- MVC,MVVM,The Clean Architectureなどいろんなアーキテクチャパターンがある.
- そもそもなんでこれらのアーキテクチャがあるのだろうか→ UI と model を分離したいというモチベーション
- で,UIとModelをつなぐ ビジネスロジック をきちんと整理していきましょう!!!
感想
- 上の話に加えて実例があったので非常にわかりやすかった.
- "名のあるアーキテクチャを採用するだけでは設計したとは言えない" が心にぶち刺さり思考停止しました...おっしゃるとおりでございます...
課題感から始めるクラス設計とチーム内での合意形成
スライド
ざっくりまとめ
- DroidKaigiでもセッションを聞きに行って感動したきりみんさん!!!
- いろいろなアーキテクチャがある理由とは?→そこに課題があるから
- 偉い人がイケてると言っているから導入というのはメリットがない. →心の声(ほんまそれ)
- 無理に凄い設計パターンを導入する必要はない.課題を解決するためにはなにをするべきかを考える.
- こういう課題があるから導入しようぜ→「それな」のながれが一番いい.
- 導入手順
- Issueベース(テキストベース)で議論を進める.
- 具体案を見せる.一部をその方針に則って実装し,PRを出してみる.
- コードベースでの議論を進める.
- リファクタする.
- 最高✌
- そして,一人で突っ走らない.設計の対象はプログラムだが,大事なのは正しい課題の認識とコミュニケーション
感想
- テキストベースの議論,一部を適用,コードベースでの議論の流れは確かにメンバーの意識を揃える上ではかなりバランスの取れた方針だと感じた.
- 個人開発や,超少人数開発だとどうしてもやりたい放題(あのアーキテクチャがすごそうだからとか,このライブラリが熱いから)とやってしまうが,サービスとなると話が変わってくるなとしみじみ感じた.
- チーム開発で,根幹に関わる部分であるからやはり正しく課題を認識して,それを共有するというのが大事なんだなぁ.
4年の開発が積み重なったアプリへのリファクタリング手法
スライド
ざっくりまとめ
- リファクタは現在進行系で某アプリをやっていたので聞く前から楽しみだった.
- いきなり,「よっしやったるでーーー!!!」って着手するのは危ない.
- なぜ→システムの特性や開発メンバのことを知らないと最適な判断は下せない.
- 元からいる開発メンバに責務分けを委ねる(これ凄いドメインエキスパートが登場するDDDっぽい感じある.)
- 使用したい技術(Rx,LiveData,Databinding,Dagger2)を全部入れると学習コストがでかくなるので,Rxだけにする.
- これすごくチームでやってるからという感じがした.自分一人なら,上にもかいたがやりたい放題やってしまいがち.
- リファクタ
- こうした結果チームで設計の話を共有し,次なる課題が見えるようになった!!!
感想
- 序盤に動いているコードにはリスペクトをという文言が出てきた.これは本当に思う.コードはやばくても動いているのだ.サービスとして成り立ってときには収益を上げているのだ.そこはリスペクトを.
- あまり学習コストということを考えて来なかったことを思った.みんなコード中にわけわからんのが出てきたら好き勝手学習してきて勝手にできるようになってるという変な先入観があった.そこもコストなんだなぁと改めて.
- 発表者の方は,すごくチームを観察してそのチームでのベストパフォーマンスをだすには?をすごく考えていた人だなぁと思った.
- Rxは強すぎるので使う機能や使い方を制限するというのは確かにと思った.(ViewでのみsubscribeやSubjectを使わないという話)
設計にみるAWA Androidアプリのこれまでとこれから
スライド
ざっくりまとめ
- AWAアンドロイドアプリの歴史を振り返る感じのスライドタイプ
- 立ち上げ期→MVCしてた
- →ビジネスロジックが色んな所に散った.→これを書く層が必要.
- →Modelが肥大化していった→責務分割が必要
- 設計改善期→設計を改善したが,設計のすり合わせがなされていなかったため,一貫性がなくなった. →これは怖いなぁと思った.きちんとコミュニケーションをとらないといけない理由が明確に見えたと思った.
- リーダビリティ,メンテナビリティ,テスタビリティの三本柱で!
- 現在進行系の設計→MVVM + LayerdArchitecture + CQRS
Repository
がデータソースを気にしてはならないという理念の基,APIをRepositoryから剥がした.- CommandとQueryをきちんと分けることで複雑性が解消された.
- QueryはFlowable,CommandはCompletableで!
- 設計は可視化しよう!!!
感想
- 設計のすり合わせがなかったがゆえに,一貫性が無くなるというのを曖昧な設計をやめ,可視化することで改善するのはいいなぁと思った.
- 設計は俺の頭にあるんだ.じゃダメなんだ.それを具体的に形にしないととつくづく感じた.
- 具体的にRxの型まで縛るとたしかに一貫性は保たれるし,やれること・やれないことを明確に示せるなぁと思った.
Yahoo! JAPANアプリのLayered Architectureについて
スライド
ざっくりまとめ
- 超大人数での開発とどう向き合うか.→チームに20人はやべぇ.
- 明確な設計方針がなかった→やべぇ.というかそれで回っていたということはプロが回してたんだなぁと思った.
- 導入したもの→Layerd Architecture.
- これを守らせるために,レイヤーごとにモジュールを切って,機械的にgradleで弾く(私もこれやりたい!!)
- 一方向に依存させる.
- 大規模なリファクタ前後での品質担保のため,Application以下はユニットテストを義務付け,Coveraveが80%→やべぇ.やべぇ.80ってやべぇ.
- 導入のメリットとして,機能追加に悩みにくくなり,新規のjoinが容易に.
- 維持する取り組み
- 他にはなかった話.多分,大規模であるがゆえの苦悩なのだろうと感じた.
- コミッター制度を導入し,レビューの責務を見てもらう(コミッターの人めちゃくちゃ大変そう)
- 平均すると1人のコミッターが4人を見てる.すごい...
- 仕様共有会→設計の可視化だ!!
- 設計レビュー会
感想
- 超大人数での開発が垣間見えた.
- 無理に多くのことを導入しようとしない.これは本当にそう.あれもこれもってするとわけがわからなくなるんだなぁ.メンバーやビジネス側の理解をもらうことは個人開発で趣味の領域だとぜんぜん意識しないなあと思った.
お寿司
- お寿司を食べながら,色んな人とお話できました.
- 登壇者の方ともお話できました.
- お話してたらお寿司を食べそこねた(うけぽ)
全体を通した感想
サービスと設計というタイトルをみて参加ボタンを押した時,私はゴリゴリの設計論の話を期待していたがいい意味で裏切られた.
それは,きりみんさんのスライドにもあった通り,改善したいのはコードだけど改善するのは人だから,コミュニケーションを適切に取らないといけない.コミュニケーションを取るにはきちんとチームを観察し,考えを共有,そして意見・意志の合致を取る必要がある. それができて初めて,使用する技術だとかアーキテクチャとか,そういう話になるのだ.
そうしないと,コードがどんどん汚くなってしまう.ビジネス的にも美味しくない結果が待ってる.開発者も気が乗らない,または,深い意味もないのに無駄に高尚なアーキテクチャを選定し,その意味を分からず使ってしまうなどなど,いろんな問題が生まれるんだなぁと思った.
今まで私はほとんど個人やかなり少数での開発で,それもただの趣味的なものだから好き勝手ライブラリを入れ,DIとか雰囲気でいけるっしょ(笑)みたいな感じで導入し,MVVMイケてるっぽいから導入しようぜ👊ってやってきたけど,これビジネスが関わってきたらまじ卍(語彙力)って結果を招いていたんだなぁとちょっと反省した.
最後に
Bonfire Android開催の運営に関わった方々,発表をしていただいた方々,懇親会でAndroidの知見をいろいろと共有していただいた参加者の方々ありがとうございました!!!!
DroidKaigi2018に参加しました
DroidKaigi2018に参加してきました.一言で感想を要約すると死ぬほど楽しくて死んだ.
参加記です.聞いたセッションのことを備忘録としてさらさらと書いてみます.
スライドはここにいろいろまとまってるっぽいです.
- DAY 01
- 朝
- ウェルカムトーク
- Kotlinアンチパターン
- スライド
- 思ったこと
- How to improve your MVP architecture and tests
- スライド
- 思ったこと
- How to Kontribute
- スライド
- 思ったこと
- DataBindingのコードを読む
- スライド
- 思ったこと
- Say bye to Fragments with Conductor & Kotlin
- スライド
- 思ったこと
- 実例で理解するMaterial Design Animation
- スライド
- 思ったこと
- Kotlin版CleanArchitectureのテンプレート作ったら爆速開発になった話+α
- スライド
- 思ったこと
- スポンサーブースを回る
- いろんな企業
- コーヒー
- After Party
- 思ったこと
- DAY 02
- コンテンツ流通基盤概論
- コードで見るFlutterアプリの実装
- スライド
- 思ったこと
- Gradleプラグインを作って開発効率を改善しよう
- スライド
- 思ったこと
- 終わった直後
- DAY -??
- 全体的な感想
AndroidのToolbarをいい感じに触る
ググったときに???みたいな記事が多い気がしたのと,タイピング練習のつもりで記事を書きます.講義が習ったことをちんたら喋ってて暇だった
あるアプリケーションをリファクタしていたら,ToolbarにActivityで直接setTitle
するコードがありました.動的になんか差し替えるならまだしも,基本的に静的なテキストはxmlで記述する方針で書いていたのでリファクタします.ついでに,onClick
まわりもいい感じにします.
こういうやつです.
コード上からsetTitleを消しさる
google先生で適当にぐぐるとtheme
をいじって...とか書いてありますが,そんなことしなくていいです.
確かにxmlファイル上で参照android:textでは設定できないけど...
xmlns:app="http://schemas.android.com/apk/res-auto"
を記述してapp:
で参照すれば良いです.つまり,
コード上で下のように書いていたものを
toolbar.setTitle("HogeFuga");
xmlで下のように書けば良い
<android.support.v7.widget.Toolbar app:title="HogeFuga"
これでsetTitle
をなくすことができました.これと同じ要領でアイコンも指定できます.
コード上からsetNavigationOnClickListenerを消し去る
ただのonClick
であれば,android:onClick
でdatabindingするといい感じにうぇい(語彙力)して終わりですが,Navigationのクリックを取るのはちょっと工夫が入ります.
同じ要領でapp:navigationOnClickListener
みたいなのはなく,android:onClick
取ってきたらToolbar全体にクリックリイベントを挿す羽目になるので,どうにかします.
BindingAdapter
BindingAdapterでクリックイベントをbindingします.これがjavaであれば,
@BindingAdapter("navigationOnClick") public static void setNavigationOnClick(Toolbar toolbar, View.OnClickListener clickListener){ toolbar.setNavigationOnClickListener(clickListener); }
とすれば良いです.これをkotlinに素直にすると,
object CustomBinder { @JvmStatic @BindingAdapter("navigationOnClick") fun onNavigationClick(toolbar: Toolbar, clickListener: View.OnClickListener) = toolbar.setNavigationOnClickListener(clickListener) }
となりますが,これは非常にダサい上に@JvmStatic
警察に捕まります(?)
なので,Toolbarの拡張関数として書いて,いい感じにすると,
@BindingAdapter("navigationOnClick") fun Toolbar.onNavigationClick(clickListener: View.OnClickListener) = setNavigationOnClickListener(clickListener)
となっていい感じにかわいい感じ(?)になって,xmlでは
app:navigationOnClick="@{viewModel::onBackButtonClicked}"
こんな感じに指定して,コードでonBackButtonClicked
の中身を書けばスッキリします.
これで,コードがスッキリした感じになりながら目的を達成できました.おわり.