Rails アプリを10年以上継続していくためのフロントエンドの底上げ

Transcript

1. Tomoya Chiba (@tomoasleep) Qiita 株式会社 Rails アプリを 10 年以上継続していくためのフロント エンドの底上げ

   1

2. Tomoya Chiba (@tomoasleep) Qiita 株式会社 共通基盤開発グループ シニアエンジニア 2013-2019: 学生アルバイト →

   正社員 2021-2022: 業務委託 2022-: 正社員 インフラ ~ バックエンド ~ フロントエンドまでやる雑 食系エンジニアです 最近の悩み: ブラックフライデーセールで安くなってい る 3D プリンタを買うかどうか 自己紹介 2

3. 今年で Qiita は ?? 歳になりました 3

4. (Qiita は 2011 年生まれ ) 今年で Qiita は 12 歳になりました

   4

5. Qiita の 12 年の変遷 (2011 2013) 5

6. Qiita Team が誕生 Qiita の 12 年の変遷 (2011 2013) 6

7. Qiita Jobs も生まれた Qiita, Qiita Team も大きく変わった Qiita の 12

   年の変遷 (2023) 7

8. ところで、 12 年前の Rails フロントエンドってどん なんだったか覚えていますか … ？ 8

9. 初期の Qiita のフロントエンドの構成技術 ( 一部 ) 9

10. 現在の Qiita のフロントエンドの構成技術 ( 一部 ) 10

11. 初期: Rails が主、一部の View を jQuery で書き換え ↓ 宣言的な記述で複雑さを減らす 中期:

    Rails が主、一部の View を React で構築 ↓ 責務の集約、ツールの生産性を求めて 現在: ページほぼ全体を React で構築 時代の変化にあわせて採用技術も変化 11

12. 技術の変化 : View の主役を Rails → JS に 12

13. (※ ただしサービスを育てるのと並行して ) 技術の変化 : View の主役を Rails → JS

    に 13

14. 使う技術の数がこんなことに！！！ どうなるか : フロントエンドが多様化してしまってい た 14

15. 様々な格差が多様化を生んでしまっていた 機能間の格差: 開発頻度の差がフロントエンドの差に サービス間の格差: 様々な戦略の違いにより。チームの知識の差にも どうなるか : フロントエンドが多様化してしまってい た 15

16. 度が過ぎた多様化は開発体験を悪化させる 同じことをする複数の実装が必要に 違いがスイッチングコストを生む 古いものもメンテし続けないといけない → 遅れてしまった部分を底上げして、差を縮めた フロントエンドを底上げして、差が出てしまった部 分を揃えた 16

17. Qiita のフロントエンドの底上げの取り組みについて 話します 17

18. Case 1: Qiita 内の機能間の格差を埋める Case 2: サービス間の格差を埋める 話す例 18

19. 長年のフロントエンドの試行錯誤により、複数の Version がある v1: Backbone, React, webpack, Bootstrap v2: Hyperapp,

    GraphQL, Rollup v3: React, GraphQL, Atomic Design, webpack Case 1: Qiita 内のフロントエンド Version の統一 19

20. v1: Backbone, React, webpack, Bootstrap v2: Hyperapp, GraphQL, Rollup v3:

    React, GraphQL, Atomic Design, webpack 開発しながら、 v3 への移行を進めていく 20

21. v1: Backbone, React, webpack, Bootstrap ( あまり触らないページが多い ) v2: Hyperapp,

    GraphQL, Rollup v3: React, GraphQL, Atomic Design, webpack あまり触っていないページが v1 のまま残る 21

22. 「ユーザーの声を聞いて、ユーザー体験向上」をミッションとするチーム 手を付けてない場所の改善 → ユーザー体験の底上げ 「古いフロントエンドの刷新」と、チームのミッションを揃えて 進める 22

23. v1: Backbone, React, webpack, Bootstrap v2: Hyperapp, GraphQL, Rollup v3:

    React, GraphQL, Atomic Design, webpack v1, v2 からの移行を達成 23

24. Qiita Team のフロントエンドは進化が遅れていた (Qiita の v1 相当) デザインリニューアルを機に、Qiita Team フロントエンドの底上げを進めること

    に Before After Case 2: Qiita と他のサービス (Qiita Team) との差 を埋める 24

25. Qiita の v3 相当へのジャンプは結構難しい ほとんどの要素を書き換えることになる これを Qiita Team のすべてのページでやる？？？ いきなりジャンプするのは難しい

    25

26. 一番達成したいことはなんだろう？ → 「View を JS だけで構築出来る状態」 それを実現できる最小ゴールを設定する GraphQL 導入は一旦やらない いきなり全部追いつこうとしない

    26

27. わかる。流石にスキーマ駆動開発の枠組みは欲しい 隙間を埋める仕組みを作って補う → JSON Schema を作る Presenter で Rails アプリケーション

    (Qiita Team) と フロントエンドの連携をする #Ruby - Qiita ※ GraphQL ないのつらくない？ 27

28. 新しいフロントエンドに慣れていないメンバーもいる Qiita の開発メンバーに、一時的に入ってもらう ペアプロで知見を共有し、学んだメンバーが他に教えて… 、で知識の差を埋める Qiita Team の開発メンバーが全員移行が行えるように チーム間の出張で、知識の差を埋める 28

29. Qiita Team の View の JS 化がほぼ完了 29

30. 自然にやっていくと、フロントエンドの格差、多様性が生まれてしまう それを改善するために… 、 「古いフロントエンドの底上げ」とチームのミッションを揃えて進める 底上げする際のゴールは無理をしない 先に進んでいるチームのノウハウを借りる ここまでの学び 30

31. View の JS 化はほぼ完了できたが… 、 まだまだ課題はたくさん サービス間の差はまだある まだまだモダンにしきれていない部分もある まだまだ Rails

    と密結合しているところがある Qiita の現在地点 31

32. 15 年 , 20 年 , ... 続くサービスのフロントエンドを目指 して 32