Tweet
Tweet

Slide 1

Slide 1 text

17周年のWebアプリケーションに TanStack Queryを導入する さいと / Muddy Web #10

Slide 2

Slide 2 text

自己紹介 ● 2022年新卒入社 (3年目) ● フロントエンドエンジニア ● 最近CloudflareとHonoが熱い ● ポケモンカードが好き さいと @saitolume

Slide 3

Slide 3 text

“好き”に出会えるイラスト・マンガ・小説作品の 投稿プラットフォーム サービス開始日　2007年9月10日 登録ユーザー数　約1億ユーザー 累計投稿作品数　約1億4000万作品

Slide 4

Slide 4 text

● 変えることは難しい ● でも、変えられる ● 変えるためには泥臭く (Muddyに) 課題に向き合うことも必要 今日伝えたいこと

Slide 5

Slide 5 text

アジェンダ ● pixivの歴史と負債 ● 変える ● 課題と向き合う ● 事例: 非同期データ管理ライブラリの導入

Slide 6

Slide 6 text

pixivの歴史と負債

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

● 2007年 pixiv誕生 ○ 個人サイトや掲示板からSNSの時代へ ○ 動的なコンテンツを扱うためPHPとSmartyで実装 pixivの歴史と負債

Slide 9

Slide 9 text

● 2010年 pixiv touch誕生 ○ ガラケーからスマホの時代へ ○ スマホに最適化するために新規で実装 pixivの歴史と負債

Slide 10

Slide 10 text

● 2018年 SPA移行 ○ 仮想DOMによる高速なレンダリングが可能なライブラリ・フレー ムワークが台頭 ○ デスクトップはReactを採用 ○ モバイル (touch) はVue.jsを採用 pixivの歴史と負債

Slide 11

Slide 11 text

● 2022年 大統一時代 ○ デスクトップとモバイルの実装が分離していることによる生産性 の低さが課題に ○ 解決するためにレスポンシブデザインの実装が増加する ○ Next.jsに移行して実装を統合するプロジェクトが始動 pixivの歴史と負債

Slide 12

Slide 12 text

● 2024年 現在 ○ Smarty、React、Vue、Next.jsの4つの実装が存在 ○ 各時代で移行しきれなかったコードが断層のように残っている ○ それぞれを切り取って見るとうまくいっていそうだったが、振り返 ると負債になっている pixivの歴史と負債

Slide 13

Slide 13 text

● 課題 ○ 実装が分散しているため作業量が多い ○ 1億人以上のユーザーに影響を与える可能性がある ○ テストが不足している ○ フロントエンドエンジニアが各チームに分散している ○ 相談先や相談する場所がない pixivの歴史と負債

Slide 14

Slide 14 text

変える

Slide 15

Slide 15 text

● ソフトウェアエンジニアはスペシャリスト ● 要求に応じて、より早くより高い質で変えることが求められる ● プラットフォームには様々な要求が発生する ○ ユーザーの声、プロダクトの方針 ○ 技術革新、法令対応、決済リスク 変える

Slide 16

Slide 16 text

● 17周年を迎えたpixivは変更容易性が低い状態 ● 変えることは難しい 変える

Slide 17

Slide 17 text

● 課題 ○ 実装が分散していて作業量が多い ○ 1億人以上のユーザーに影響を与える可能性がある ○ テストが不足している ○ フロントエンドエンジニアが各チームに分散している ○ 相談先や相談する場所がない pixivの歴史と負債 (再掲)

Slide 18

Slide 18 text

課題と向き合う

Slide 19

Slide 19 text

● ゴールを「変更容易性を手に入れること」とする ● 何を得られると変えられるようになるのか ○ 人月 ○ 堅牢な設計 ○ テスト ○ ？？ 課題と向き合う

Slide 20

Slide 20 text

● pixivに最も必要だったものは「合意」 ○ 1つのプロダクトを複数のチームで開発している ○ 個人やチームで完結できない ○ 変えるときにやっていいのか不安になる ○ いざやってみても手戻りが発生するリスクがある 課題と向き合う

Slide 21

Slide 21 text

● 失敗事例 ○ 2023年末にApp Routerを導入しようとした ○ 一部ページを移行する実装のレビューをお願いしたときに、設計 で折り合いがつかなかった ○ 凍結へ 課題と向き合う

Slide 22

Slide 22 text

● 合意に必要なもの ○ 意思決定の仕組み ○ 意思決定の場所 課題と向き合う

Slide 23

Slide 23 text

意思決定の仕組み

Slide 24

Slide 24 text

● Architecture Decision Record (ADR) を導入 ● ソフトウェア開発における意思決定を文書化する手法 ● 文脈、選択内容、選択理由などを記録 ● 後から辿ることができる ○ “なぜフェンスが建てられたのかわかるまで、決してフェンスをと りはずしてはならない” 意思決定の仕組み

Slide 25

Slide 25 text

● ルール ○ 開発者全員が提案・コメントできる ○ 提案者は提案に責任を持って進行する ○ 提案内容は同期的に意思決定される (後述) 意思決定の仕組み

Slide 26

Slide 26 text

● テンプレート ○ 文脈: どのような状況で選択が迫られているか ○ 選択: 意思決定の内容 ○ 比較・検討: 事実ベースで選択に必要な情報をまとめる ○ 結果: 意思決定がシステムやメンバーに与える影響 意思決定の仕組み

Slide 27

Slide 27 text

● 変えるためのレールが敷かれた ○ レールに乗って進めば変えられる！ ○ わかりやすくなった ○ やることが減った ○ 心理的なハードルが低くなった 意思決定の仕組み

Slide 28

Slide 28 text

意思決定の場所

Slide 29

Slide 29 text

● フロントエンドエンジニアが集まって同期的に話す会を開催 ○ 隔週 ○ 誰でも参加可能 ○ 最大30分 ○ トピックがないときは解散 意思決定の場所

Slide 30

Slide 30 text

● テンプレート ○ 前回までの宿題 ○ 今週の議題 ○ 更新・追加された開発マニュアルの確認 ○ 提案中のADRの確認 意思決定の場所

Slide 31

Slide 31 text

● 場所ができると人が集まってくる ○ 今までは別チームにいて議論することが少なかった人も ○ 関心が可視化されて雰囲気が良くなった ○ カイゼンに伴う孤独感が薄れる 意思決定の場所

Slide 32

Slide 32 text

● 納得感 ○ オープンな場所で透明性がある ○ 関心のあるメンバーが集まっている ○ 「フロントエンドで悩んだらあそこで決めよう」 意思決定の場所

Slide 33

Slide 33 text

● 実績 ○ ちょうど1年間継続 (計23回開催) ○ 62件のトピックを議論 ○ 11人がトピックを起票 ○ 25件の意思決定をサポート 意思決定の場所

Slide 34

Slide 34 text

事例: 非同期データ管理ライブラリ

Slide 35

Slide 35 text

● 2023年5月 Slackではじめて言及される ○ 当時はADRも会もなかったので話が進まない ● 2024年2月 会のトピックに上がる ● 2024年4月 ？？ ● 2024年5月 検討を再開 ● 2024年8月 承認・導入 🎉 事例: 非同期データ管理ライブラリ

Slide 36

Slide 36 text

● 検討から導入まで3ヶ月かかった ● 最初は隔週の会だけで話していて期間が空いてしまった ● 主務の部署の業務が優先されるため、優先度が下がりがち ● 開発者によって選択肢に好みがある ○ SWR、TanStack Query、RTK Queryなど ○ 納得感の醸成が必要 事例: 非同期データ管理ライブラリ

Slide 37

Slide 37 text

● 隙間時間を活用してプロトタイピング ○ ライブラリごとの違いを客観的に評価 ○ コードを見ながら議論する ● 目的と手段を見比べる ○ 例えば、目的の1つに「Reduxをやめたい」もある ○ RTK QueryだとReduxへの依存をやめられない 事例: 非同期データ管理ライブラリ

Slide 38

Slide 38 text

● 結論 ○ TanStack Queryを選択 ● 理由 ○ クエリ単位で抽象化ができる ○ context.metaを活用できる ○ SWRは既存のAPIクライアントクラスと相性が悪かった ○ など 事例: 非同期データ管理ライブラリ

Slide 39

Slide 39 text

● 意思決定の仕組みと場所があるおかげで話を進められた ● ADRで選択肢の比較と意思決定の記録ができた ● 会が定期的に開かれていることで気軽に提案できる 事例: 非同期データ管理ライブラリ

Slide 40

Slide 40 text

● 2023年5月 Slackではじめて言及される ○ 当時はADRも会もなかったので話が進まない ● 2024年2月 会のトピックに上がる ● 2024年4月 ？？ ● 2024年5月 検討を再開 ● 2024年8月 承認・導入 🎉 事例: 非同期データ管理ライブラリ (再掲)

Slide 41

Slide 41 text

● 2023年5月 Slackではじめて言及される ○ 当時はADRも会もなかったので話が進まない ● 2024年2月 会のトピックに上がる ● 2024年4月 Muddy Web #8 でTanStack Query導入の話を聞く ● 2024年5月 検討を再開 ● 2024年8月 承認・導入 🎉 事例: 非同期データ管理ライブラリ

Slide 42

Slide 42 text

Muddy Webがきっかけで モチベーションを高められました 感謝🙏

Slide 43

Slide 43 text

まとめ

Slide 44

Slide 44 text

● pixivは17年の積み重ねで変えることが難しくなっていた ● 変えられる状態 = 変更容易性を手に入れたい ● そのためにADRと場所をつくって運用している ● 成果の1つとして、TanStack Queryの導入ができた まとめ

Slide 45

Slide 45 text

● 変えることは難しい ● でも、変えられる ● 変えるためには泥臭く (Muddyに) 課題に向き合うことも必要 今日伝えたいこと (再掲)

Slide 46

Slide 46 text

● ピクシブは一緒に「創作活動を、もっと楽しくする。」メンバーを募集し ています ● pixivのフロントエンドにはまだ課題が山積み ● しかし、それらを変えられるベースができてきた ● 一緒に挑戦したい方をお待ちしています 最後に https://hrmos.co/pages/pixiv/jobs