App Client Melting Pot #1「設計」 に行ってきました。そして年始の誓いに沿って登壇をと思い、今回は懇親会LTにいれた、のでしたが…!
各発表の感想
FiNCのクライアントアーキテクチャを揃える試み
昨日の発表資料アップロードしましたー
— takasek (@takasek) January 11, 2019
FiNCのクライアントアーキテクチャを揃える試み / 20190110 #app_mp - Speaker Deckhttps://t.co/bWmRKwWPOf
感想
- iOSとAndroidを並走させることにおいての知見の塊
- Viewはバインディングできる素養が揃っているからMVVMで、ObservableをRxで実現するのは理にかなっている。
- Rxのオペレーターって揃ってないんだっていうのは学び
- ジェネリクスでResourceを作るのとても良いと思ったが、InProgressの進捗度は認識併せないと変な使い方しそうな気配がすごいした
- ドキュメントでルール敷くよりもサンプルプロジェクトで敷くっていい考え方だなと思ったので、いろんな場面で使っていけそう
関連リンク
- ReactiveX - Rxの基本的な説明があるサイト、ただし英語
- Result
V.S. Result<T, E> - Speaker Deck - NoErrorの考え方はなるほどなー!という感じ
実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~
https://t.co/WkHcnmYPGZ
— Kensuke Izumi (@izmeal2000) January 10, 2019
Android / iOSの設計共有の文脈でお話しします〜#app_mp
感想
- 実は過去に見ている が改めて聞いて発見があった
- 結構ネットワーク遅延(レイテンシ)を下げるために割と一個のAPIに盛り盛りにしがちだが、それで返って遅くなるケースってあるよねとか思った
- ユーザ体験のトライアンドエラーをやるなら、Webにそれを寄せようという考え方は大切だなと思った。(おそらく今は面影なきMERYもJSONでパーツを表現してそれをクライアントで組み立てるみたいな手法を紹介していた気がする ※情報ソースが藻屑になって消えたのでぼんやり)
- BFFとのコミュニケーションコスト高いので、そこを自力解決は改めてやりたいけどできない決断なのですげーなという気持ち
関連リンク
- WebFluxとKotlinでReactive Web - JavaはAndroidでしか触れてないのでSpringとかぼんやりレベルしかしらないので未知の世界…
2つの同期 4つの状態
2つの同期 4つの状態 #app_mp #architecture https://t.co/dsIxypMXlk @SlideShareさんから
— 🗼ダンボー田中@本が出た🎉 (@ktanaka117) January 10, 2019
先ほどの発表資料です🙋♀️#app_mp
感想
- 同期の種類、頭では理解していたけどこうやって体系づけされていたのかという学び
- ステートの種類も確かにコレぐらいに分類できるなという学び、ただPresentationが結構わかりにくさあるなと感じた。
- 後半はStateを題材にしながらもGUIアーキテクチャの事例カタログ集みたいになってて読み返したくなるスライドでした。
- あとラグランパンチ(だと思われるフォント)使うとメリハリついてよいなーと思った。
関連リンク
- Martin Fowler: eaaDev - この資料内でも紹介されていたパターンも含めたMartin Fowlerのエンタープライズアプリケーションアーキテクチャのパターン紹介ページ
設計の話をする前にすり合わせしたい言葉
昨日の発表をちょいっとまとめた >
— しんくう (@shinkuFencer) January 10, 2019
『設計の話をする前にすり合わせしたい言葉』という内容で登壇してきました。 - コード日進月歩 https://t.co/Xd0w15LpPw #はてなブログ
登壇した感想
- まさかの繰り上げ通常枠での発表、直前打診されてびっくり。
- 「みんな割と手堅い内容で来るはずだし、懇親会用だしあっさりしたものにしよう」とか思ってたので設計を語り合うまえに…みたいな感じに仕上げました。
- JSONの話はウケてよかった。
関連リンク
- 多層アーキテクチャが生まれた利点を考える - コード日進月歩 - レイヤードアーキテクチャも原点調べようと思って挫折したので痕跡だけメモった記事
パネルディスカッション
トークメモ
ロジックをサーバ、クライアント、どっちに置く?
- 表示に関わることだからPresentationであるクライアントに起きたい…というのはあるがアプリはアップデートの兼ね合いがあるので難しい
- 面白くない答えにはなってしまうがケースバイケース
- エラーメッセージとか概念的にはViewだがサーバに持たせるかというところは悩みどころ
- iOS/Androidはプラットフォームごとに表現のレギュレーションが違ったりするので、そういうロジックはクライアントが持つ、という考えもある
設計はどう決めたか
- チームの練度や技量によって異なってくる
- 設計は機能によって変わってくるので、機能を考えてアーキテクチャパターンを考える
- 設計はレールである、盤石なレールは山手線のようなもので遠回りしてでも確実につくることができる。山手線の真ん中を通り抜けてショートカットするような中央線のようなものをつくりたい場合はそのショートカットした仕様を保つことができるのであればやればいいし、保つことができないのならやめたほうがいい。
- やりたい事業に併せてつくっていくので、事業会社としては事業を成長させる設計が正解、という考えもある
設計のレベルアップをどうやっているか
- 新しい設計パターンが出たらサンプルコードをやる
- アーキテクチャができた経緯や真意を調べる、そこから自分の知ってる方法との差異や、どういう問題に対して生み出されたものかがわかる。ちゃんと調べたければ論文などにあたるとよい
- 小さく始めて、大きくしたときに鞍替えできるかみたいな観点でやっておくとよい
- パターンは問題解決のためのもの、パターンを覚えていき、いろいろ使うことで設計力をあげていく。
感想
- 急遽行われたパネルディスカッション。自分の発表の後だったのでメモが結構半端だったのでちょっとぼんやりめ。
- レールを使うのがいいのか悪いのかで山手線と中央線の例が出て、レールになぞらえて面白い話だった。東京在住の人なら使えるたとえ。
- 知識の原点は論文やホワイトペーパーをあたるという行動はすごい大事だなと思っているので、そこらへんのリサーチ力あげたいなと思った。
関連リンク
- Building reactive Android apps with MVI – ProAndroidDev - ディスカッションで出てきた新たな考え方
全体を通しての感想
- iOSとAndroidの垣根を超えた勉強会って感じでしたが、自分みたいなエンジニアの人もいたので結構面白かったです。クライアントという観点でいけばJS的なところもいてもよさそう
- しんぺいさんの話は聞けなかったのは残念でしたが、それが転じて自分としてはいい機会を与えていただきありがとうございます。という感じ
- 懇親会も結構いろいろ喋れて、他の会社の作り方とかしれてよかった。次もあればひっそりと参加したい会でした。