遅くなってごめんなさい．完全に私の怠慢です．
なんかそれ，発表のときに伝えたかったニュアンスとズレてる🤔🤔🤔というときは 指摘していただけると助かります．
はじめに
3/12に参加してきました．
yj-meetup.connpass.com
今回のテーマは サービスと設計 という，話を聞いているとだんだん耳が痛くなって途中退出したくなる系(?)だけどめちゃくちゃためになる話でした．
Androidアプリにおけるソフトウェア設計の考え方
スライド
speakerdeck.com
ざっくりまとめ
- MVC，MVVM，The Clean Architectureなどいろんなアーキテクチャパターンがある．
- そもそもなんでこれらのアーキテクチャがあるのだろうか→ UI と model を分離したいというモチベーション
- で，UIとModelをつなぐ ビジネスロジック をきちんと整理していきましょう！！！
- どうやって？
- OOAD(オブジェクト指向分析設計)→ SOLID原則*1 や UML を使いながらまとめる．
- DDD(ドメイン駆動設計)→エリック・エヴァンスのDDD本を読もう！(私も夏に呼んで以来ほとんど復習できてない)
感想
- 上の話に加えて実例があったので非常にわかりやすかった．
- "名のあるアーキテクチャを採用するだけでは設計したとは言えない" が心にぶち刺さり思考停止しました．．．おっしゃるとおりでございます．．．
課題感から始めるクラス設計とチーム内での合意形成
スライド
speakerdeck.com
ざっくりまとめ
- DroidKaigiでもセッションを聞きに行って感動したきりみんさん！！！
- いろいろなアーキテクチャがある理由とは?→そこに課題があるから
- 偉い人がイケてると言っているから導入というのはメリットがない． →心の声(ほんまそれ)
- 無理に凄い設計パターンを導入する必要はない．課題を解決するためにはなにをするべきかを考える．
- こういう課題があるから導入しようぜ→「それな」のながれが一番いい．
- 導入手順
- Issueベース(テキストベース)で議論を進める．
- 具体案を見せる．一部をその方針に則って実装し，PRを出してみる．
- コードベースでの議論を進める．
- リファクタする．
- 最高✌
- そして，一人で突っ走らない．設計の対象はプログラムだが，大事なのは正しい課題の認識とコミュニケーション
感想
- テキストベースの議論，一部を適用，コードベースでの議論の流れは確かにメンバーの意識を揃える上ではかなりバランスの取れた方針だと感じた．
- 個人開発や，超少人数開発だとどうしてもやりたい放題(あのアーキテクチャがすごそうだからとか，このライブラリが熱いから)とやってしまうが，サービスとなると話が変わってくるなとしみじみ感じた．
- チーム開発で，根幹に関わる部分であるからやはり正しく課題を認識して，それを共有するというのが大事なんだなぁ．
4年の開発が積み重なったアプリへのリファクタリング手法
スライド
speakerdeck.com
ざっくりまとめ
- リファクタは現在進行系で某アプリをやっていたので聞く前から楽しみだった．
- いきなり，「よっしやったるでーーー！！！」って着手するのは危ない．
- なぜ→システムの特性や開発メンバのことを知らないと最適な判断は下せない．
- 元からいる開発メンバに責務分けを委ねる(これ凄いドメインエキスパートが登場するDDDっぽい感じある．)
- 使用したい技術(Rx，LiveData，Databinding，Dagger2)を全部入れると学習コストがでかくなるので，Rxだけにする．
- これすごくチームでやってるからという感じがした．自分一人なら，上にもかいたがやりたい放題やってしまいがち．
- リファクタ
- Layerdアーキテクチャな感じにして，一方向に依存させる．逆方向はRxのストリームを流す．
Viewからロジックを剥がす．→これは修行だ．．．- ロジックはドメインにまかせて似た処理がバラバラ事件になってるのを収束させる．
- こうした結果チームで設計の話を共有し，次なる課題が見えるようになった！！！
感想
- 序盤に動いているコードにはリスペクトをという文言が出てきた．これは本当に思う．コードはやばくても動いているのだ．サービスとして成り立ってときには収益を上げているのだ．そこはリスペクトを．
- あまり学習コストということを考えて来なかったことを思った．みんなコード中にわけわからんのが出てきたら好き勝手学習してきて勝手にできるようになってるという変な先入観があった．そこもコストなんだなぁと改めて．
- 発表者の方は，すごくチームを観察してそのチームでのベストパフォーマンスをだすには？をすごく考えていた人だなぁと思った．
- Rxは強すぎるので使う機能や使い方を制限するというのは確かにと思った．(ViewでのみsubscribeやSubjectを使わないという話)
スライド
speakerdeck.com
ざっくりまとめ
- AWAアンドロイドアプリの歴史を振り返る感じのスライドタイプ
- 立ち上げ期→MVCしてた
- →ビジネスロジックが色んな所に散った．→これを書く層が必要．
- →Modelが肥大化していった→責務分割が必要
- 設計改善期→設計を改善したが，設計のすり合わせがなされていなかったため，一貫性がなくなった． →これは怖いなぁと思った．きちんとコミュニケーションをとらないといけない理由が明確に見えたと思った．
- リーダビリティ，メンテナビリティ，テスタビリティの三本柱で！
- 現在進行系の設計→MVVM + LayerdArchitecture + CQRS
Repositoryがデータソースを気にしてはならないという理念の基，APIをRepositoryから剥がした．- CommandとQueryをきちんと分けることで複雑性が解消された．
- QueryはFlowable，CommandはCompletableで！
- 設計は可視化しよう！！！
感想
- 設計のすり合わせがなかったがゆえに，一貫性が無くなるというのを曖昧な設計をやめ，可視化することで改善するのはいいなぁと思った．
- 設計は俺の頭にあるんだ．じゃダメなんだ．それを具体的に形にしないととつくづく感じた．
- 具体的にRxの型まで縛るとたしかに一貫性は保たれるし，やれること・やれないことを明確に示せるなぁと思った．
Yahoo! JAPANアプリのLayered Architectureについて
スライド
speakerdeck.com
ざっくりまとめ
- 超大人数での開発とどう向き合うか．→チームに20人はやべぇ．
- 明確な設計方針がなかった→やべぇ．というかそれで回っていたということはプロが回してたんだなぁと思った．
- 導入したもの→Layerd Architecture．
- これを守らせるために，レイヤーごとにモジュールを切って，機械的にgradleで弾く(私もこれやりたい！！)
- 一方向に依存させる．
- 大規模なリファクタ前後での品質担保のため，Application以下はユニットテストを義務付け，Coveraveが80%→やべぇ．やべぇ．80ってやべぇ．
- 導入のメリットとして，機能追加に悩みにくくなり，新規のjoinが容易に．
- 維持する取り組み
- 他にはなかった話．多分，大規模であるがゆえの苦悩なのだろうと感じた．
- コミッター制度を導入し，レビューの責務を見てもらう(コミッターの人めちゃくちゃ大変そう)
- 平均すると1人のコミッターが4人を見てる．すごい．．．
- 仕様共有会→設計の可視化だ！！
- 設計レビュー会
感想
- 超大人数での開発が垣間見えた．
- 無理に多くのことを導入しようとしない．これは本当にそう．あれもこれもってするとわけがわからなくなるんだなぁ．メンバーやビジネス側の理解をもらうことは個人開発で趣味の領域だとぜんぜん意識しないなあと思った．
お寿司
- お寿司を食べながら，色んな人とお話できました．
- 登壇者の方ともお話できました．
- お話してたらお寿司を食べそこねた(うけぽ)
全体を通した感想
サービスと設計というタイトルをみて参加ボタンを押した時，私はゴリゴリの設計論の話を期待していたがいい意味で裏切られた．
それは，きりみんさんのスライドにもあった通り，改善したいのはコードだけど改善するのは人だから，コミュニケーションを適切に取らないといけない．コミュニケーションを取るにはきちんとチームを観察し，考えを共有，そして意見・意志の合致を取る必要がある．
それができて初めて，使用する技術だとかアーキテクチャとか，そういう話になるのだ．
そうしないと，コードがどんどん汚くなってしまう．ビジネス的にも美味しくない結果が待ってる．開発者も気が乗らない，または，深い意味もないのに無駄に高尚なアーキテクチャを選定し，その意味を分からず使ってしまうなどなど，いろんな問題が生まれるんだなぁと思った．
今まで私はほとんど個人やかなり少数での開発で，それもただの趣味的なものだから好き勝手ライブラリを入れ，DIとか雰囲気でいけるっしょ（笑）みたいな感じで導入し，MVVMイケてるっぽいから導入しようぜ👊ってやってきたけど，これビジネスが関わってきたらまじ卍(語彙力)って結果を招いていたんだなぁとちょっと反省した．
最後に
Bonfire Android開催の運営に関わった方々，発表をしていただいた方々，懇親会でAndroidの知見をいろいろと共有していただいた参加者の方々ありがとうございました！！！！
