【PIXIV MEETUP 2023】ピクシブ決済基盤のフロントエンドを改善していく話

Transcript

1. pixiv Inc. ピクシブ決済基盤の フロントエンドを 改善していく話 @yamasho
2. Profile yamasho フロントエンドエンジニア • 2023/04 中途入社 • フロントエンド歴5年 • 最近ハマっているものは いろいろな味のサバ缶
3. 今日話すこと • ピクシブ決済基盤とフロントエンドの課題について • どう解決するか ◦ 技術選定について ◦ 断続的なリプレイス戦略について • まとめ
4. 今日話さないこと • 詳細な実装の内容 • 各ライブラリや用語の説明(一部を除く) • いろいろな味のサバ缶について
5. ピクシブ決済基盤 について
6. ピクシブ決済基盤について • カード一覧/選択/登録画面 • 決済前確認画面 • 銀行口座入力画面 • etc… 主な画面
7. カード登録画面
8. 決済前確認画面
9. フロントエンドについて • Scala/Play Framework + テンプレートエンジン (twirl) • 基本VanillaJS(少しだけjQuery) • Storybook(htmlが2重管理されてる) • Tailwind CSSを使用した弊社デザインシステム • メンテナンスが滞っている
10. フロントエンド専任は yamashoのみ
11. ピクシブ決済基盤 フロントエンドの 改善できそうな課題
12. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い
13. 主に開発体験や 堅牢性部分の不安 → 改修のハードル
14. どう解決していくか
15. コンポーネント化から モダンフロントエンドの 領域を作り、 改修のハードルを下げる
16. コンポーネント化から モダンフロントエンドの 領域を作り、 改修のハードルを下げる テスト 型安全 再利用性 宣言的UI
17. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い
18. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い 脱テンプレートエンジン コンポーネント管理(TSX)
19. 技術選定について
20. 1. 脱テンプレートエンジン
21. バックエンドからの データの受け渡し方法
22. アプリケーションは常に Growthしていくもの
23. チーム状況的に リプレイスに注力は 難しい時期もある
24. コストの軽い コンポーネント化に 注力する
25. 脱テンプレートエンジン → 後回しでいいという選択
26. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い 脱テンプレートエンジン コンポーネント管理(TSX)
27. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い テンプレートエンジン上で コンポーネント管理(TSX)
28. 2. コンポーネントの管理
29. ピクシブ社内では ReactやNext.jsが人気
30. 社内の知見が多いのは かなり魅力的
31. 選ばれたのは Preactでした
32. Preactとは • とにかく軽量な仮想DOM系ライブラリ • Reactとほぼ同様のコードでコンポーネント作成が可能 • Reactとエコシステムの互換性が高い （が、苦戦したという話もチラホラ…） → 今回の用途はあくまでコンポーネント化
33. function Counter() { const [value, setValue] = useState(0); const increment = useCallback(() => { setValue(value + 1); }, [value]); return ( <div> Counter: {value} <button onClick={increment}>Increment</button> </div> ); }
34. 選ばれた理由 • 目的を絞って最小限の機能で使う → バンドルサイズを最小限に • Reactとほぼ同様のコード → Preactで苦しみを感じた際、Reactへ移行しやすい • Web Components出力をサポート → テンプレートエンジンに組み込みやすい
35. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い テンプレートエンジン上で コンポーネント管理(TSX)
36. 改善できそうな課題 • テストが充実していない • 型安全でない（TypeScriptでない） • 命令的UIによる可読性 • フロントエンドとバックエンドが密結合 • 統一されたデザインに対してUIが再利用されていない • Storybookとテンプレートエンジンの親和性が低い テンプレートエンジン上で Preactを使った コンポーネント管理(TSX)
37. 断続的なリプレイス戦略
38. 今までの経験
39. 技術選定 今まで経験したリプレイス リリース! リリースまでの流れ アプリケーションのリプレイス 新機能A 新機能Aの取り込み レガシー リプレイス バグ修正 バグ修正 取り込み 既存の凍結期間
40. 苦しかった点 • 一定期間大量にリソースを消費する • 現行システムとの同期を取ることに工数を使う ◦ 凍結期間でアプリケーションのGrowthが止まる • リリースまでの期間が長く伸びやすい ◦ 技術選定の事情も変化していく • 関わり方でリプレイスに対する意識の乖離が起きる
41. 長期戦故の消耗
42. 今回
43. 環境構築 リリースまでの流れ 既存機能A リプレイス 新機能A レガシー リプレイス バグ修正 新機能A リプレイス VRT 導入 新機能B 作成 リリース リリース リリース リリース 予定 断続的リプレイス LP作ったり
44. 昔: アプリケーションの技術刷新 今: 機能ごとのコンポーネント化
45. 小さい課題を短期間で 片付けていくことが可能
46. アプリケーションの Growthを止める事なく 断続的に改善していく
47. まとめ • 課題を管理し、現在のチームの状態に合う選択を ◦ 今回の話: リソースを考慮し、目的を絞った上での 負荷の少ない技術選定とリリース計画 • 改善タスクに完璧な終わりはない → 常に新陳代謝を繰り返す気持ち
48. Fluxライブラリは眼鏡のようなものです: あなたが必 要な時にいつでも分かるのです。 --Dan Abramov(Redux開発者)
49. ありがとうございました