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

Transcript

1. pixiv Inc.
   ピクシブ決済基盤の
   フロントエンドを
   改善していく話
   @yamasho
   

   View Slide

2. Profile
   yamasho
   フロントエンドエンジニア
   ● 2023/04 中途入社
   ● フロントエンド歴5年
   ● 最近ハマっているものは
   いろいろな味のサバ缶
   

   View Slide

3. 今日話すこと
   ● ピクシブ決済基盤とフロントエンドの課題について
   ● どう解決するか
   ○ 技術選定について
   ○ 断続的なリプレイス戦略について
   ● まとめ
   

   View Slide

4. 今日話さないこと
   ● 詳細な実装の内容
   ● 各ライブラリや用語の説明(一部を除く)
   ● いろいろな味のサバ缶について
   

   View Slide

5. ピクシブ決済基盤
   について
   

   View Slide

6. ピクシブ決済基盤について
   ● カード一覧/選択/登録画面
   ● 決済前確認画面
   ● 銀行口座入力画面
   ● etc…
   主な画面
   

   View Slide

7. カード登録画面
   

   View Slide

8. 決済前確認画面
   

   View Slide

9. フロントエンドについて
   ● Scala/Play Framework + テンプレートエンジン
   (twirl)
   ● 基本VanillaJS(少しだけjQuery)
   ● Storybook(htmlが2重管理されてる)
   ● Tailwind CSSを使用した弊社デザインシステム
   ● メンテナンスが滞っている
   

   View Slide

10. フロントエンド専任は
    yamashoのみ
    

    View Slide

11. ピクシブ決済基盤
    フロントエンドの
    改善できそうな課題
    

    View Slide

12. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    

    View Slide

13. 主に開発体験や
    堅牢性部分の不安
    → 改修のハードル
    

    View Slide

14. どう解決していくか
    

    View Slide

15. コンポーネント化から
    モダンフロントエンドの
    領域を作り、
    改修のハードルを下げる
    

    View Slide

16. コンポーネント化から
    モダンフロントエンドの
    領域を作り、
    改修のハードルを下げる
    テスト
    型安全 再利用性
    宣言的UI
    

    View Slide

17. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    

    View Slide

18. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    脱テンプレートエンジン
    コンポーネント管理(TSX)
    

    View Slide

19. 技術選定について
    

    View Slide

20. 1. 脱テンプレートエンジン
    

    View Slide

21. バックエンドからの
    データの受け渡し方法
    

    View Slide

22. アプリケーションは常に
    Growthしていくもの
    

    View Slide

23. チーム状況的に
    リプレイスに注力は
    難しい時期もある
    

    View Slide

24. コストの軽い
    コンポーネント化に
    注力する
    

    View Slide

25. 脱テンプレートエンジン
    → 後回しでいいという選択
    

    View Slide

26. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    脱テンプレートエンジン
    コンポーネント管理(TSX)
    

    View Slide

27. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    コンポーネント管理(TSX)
    

    View Slide

28. 2. コンポーネントの管理
    

    View Slide

29. ピクシブ社内では
    ReactやNext.jsが人気
    

    View Slide

30. 社内の知見が多いのは
    かなり魅力的
    

    View Slide

31. 選ばれたのは
    Preactでした
    

    View Slide

32. Preactとは
    ● とにかく軽量な仮想DOM系ライブラリ
    ● Reactとほぼ同様のコードでコンポーネント作成が可能
    ● Reactとエコシステムの互換性が高い
    （が、苦戦したという話もチラホラ…）
    → 今回の用途はあくまでコンポーネント化
    

    View Slide

33. function Counter() {
    const [value, setValue] = useState(0);
    const increment = useCallback(() => {
    setValue(value + 1);
    }, [value]);
    return (
    
    Counter: {value}
    Increment
    
    );
    }
    

    View Slide

34. 選ばれた理由
    ● 目的を絞って最小限の機能で使う
    → バンドルサイズを最小限に
    ● Reactとほぼ同様のコード
    → Preactで苦しみを感じた際、Reactへ移行しやすい
    ● Web Components出力をサポート
    → テンプレートエンジンに組み込みやすい
    

    View Slide

35. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    コンポーネント管理(TSX)
    

    View Slide

36. 改善できそうな課題
    ● テストが充実していない
    ● 型安全でない（TypeScriptでない）
    ● 命令的UIによる可読性
    ● フロントエンドとバックエンドが密結合
    ● 統一されたデザインに対してUIが再利用されていない
    ● Storybookとテンプレートエンジンの親和性が低い
    テンプレートエンジン上で
    Preactを使った
    コンポーネント管理(TSX)
    

    View Slide

37. 断続的なリプレイス戦略
    

    View Slide

38. 今までの経験
    

    View Slide

39. 技術選定
    今まで経験したリプレイス
    リリース!
    リリースまでの流れ
    アプリケーションのリプレイス
    新機能A
    新機能Aの取り込み
    レガシー
    リプレイス
    バグ修正
    バグ修正
    取り込み
    既存の凍結期間
    

    View Slide

40. 苦しかった点
    ● 一定期間大量にリソースを消費する
    ● 現行システムとの同期を取ることに工数を使う
    ○ 凍結期間でアプリケーションのGrowthが止まる
    ● リリースまでの期間が長く伸びやすい
    ○ 技術選定の事情も変化していく
    ● 関わり方でリプレイスに対する意識の乖離が起きる
    

    View Slide

41. 長期戦故の消耗
    

    View Slide

42. 今回
    

    View Slide

43. 環境構築
    リリースまでの流れ
    既存機能A
    リプレイス
    新機能A
    レガシー
    リプレイス
    バグ修正
    新機能A
    リプレイス
    VRT
    導入
    新機能B
    作成
    リリース リリース リリース
    リリース
    予定
    断続的リプレイス
    LP作ったり
    

    View Slide

44. 昔: アプリケーションの技術刷新
    今: 機能ごとのコンポーネント化
    

    View Slide

45. 小さい課題を短期間で
    片付けていくことが可能
    

    View Slide

46. アプリケーションの
    Growthを止める事なく
    断続的に改善していく
    

    View Slide

47. まとめ
    ● 課題を管理し、現在のチームの状態に合う選択を
    ○ 今回の話: リソースを考慮し、目的を絞った上での
    負荷の少ない技術選定とリリース計画
    ● 改善タスクに完璧な終わりはない
    → 常に新陳代謝を繰り返す気持ち
    

    View Slide

48. Fluxライブラリは眼鏡のようなものです: あなたが必
    要な時にいつでも分かるのです。
    --Dan Abramov(Redux開発者)
    

    View Slide

49. ありがとうございました
    

    View Slide