KEPPLE DB リプレースにおける技術的負債のバランス感覚

株式会社ビットキーさん主催のイベント「フロントエンドリプレイスにおける苦悩と工夫 〜React/Next.js編〜」で発表させていただいた際に使用したスライドです。

喋り主体だったのでスライドに書いていない内容も多いですが参考になれば嬉しいです。

Transcript

1. KEPPLE DB リプレースにおける 技術的負債のバランス感覚 芹田 悠一郎 @株式会社ケップル KEPPLE CREATORS LAB
2. • 株式会社ケップル KEPPLE CREATORS LAB 所属 • エンジニアとして働き始めてほぼ7年 • ケップルにジョインして2年弱 • フルスタック的に Web まわりのエンジニア をやっています • とにかくコーヒーが好き 芹田　悠一郎 Yuichiro SERITA
3. 背景
4. KEPPLE DB のフロント、 作り直しました
5. KEPPLE DB って何？
6. KEPPLE DB • スタートアップ投資家向けのサービス • スタートアップと投資家のデータベース • 「スタートアップ」「投資家」「ニュース」などのデータに対して検索・フィルタ
7. KEPPLE DB
8. KEPPLE DB
9. KEPPLE DB の性質 • スタートアップ・投資家の数は 2 万社くらい （どんどん増える） • スタートアップ 1 社あたり、フロントで表示しているプロパティは ざっくり数十個くらいのオーダー （じわじわ増える）
10. KEPPLE DB の性質 (ビジネス観点) • ケップルのプロダクト部門の投資家向けサービスの主力 • ほぼ毎週ユーザーに見えるアップデートをしたい • でっかい機能追加もしたい • その上、長期間無理なく運用したい
11. Q. なぜ作り直した？
12. A. 技術的負債がキツい。
13. 課題 • KEPPLE DB は高頻度でリリースしたい が…… • KEPPLE DB は KEPPLE CRM の一機能だった • KEPPLE CRM はリリース時にサービス停止が必要 • KEPPLE CRM は 2018 年リリースで、 リプレースを決断した時点で 5年間機能追加したり消したりしていろいろしんどくなっている
14. 課題 （フロント） • React で書かれている素の SPA で規模拡大に課題 • いろいろなライブラリのバージョンが古い • 魔改造されたコンポーネントが多くてバージョンが上げられない • かつて Internet Explorer に苦しめられた結果残ったメンテしづらいコード
15. KEPPLE DB は独立させ リプレースしよう
16. 旧構成 フロント バック データ ソース
17. 新構成 フロント BFF バック データ ソース New!
18. 新構成 BFF フロント NestJS GraphQL Next.js (Pages Router) Jotai Mantine Radix UI urql
19. 本題
20. 技術的負債のバランス感覚
21. 技術的負債とは？
22. 技術的負債とは (本セッションでの定義) • 短期的に見ると便利だったが、時間が経つにつれ脚を引っ張るようになったもの • あらゆるコードは必ず負債になる • 負債になりづらいコードはあるが負債にならないコードはない • 負債になりづらさを追求すると開発速度が落ちる （無借金経営）
23. 技術的負債とは (本セッションでの定義) • 短期的に見ると便利だったが、時間が経つにつれ脚を引っ張るようになったもの • あらゆるコードは必ず負債になる • 負債になりづらいコードはあるが負債にならないコードはない • 負債になりづらさを追求すると開発速度が落ちる （無借金経営） バランス感覚が大事
24. 負債になりづらさと開発速度
25. 負債になりづらいコードとは？
26. 逆に、負債になりやすいコードとは？
27. フロントで何が負債になっていたか？ • React Router と密に結合したロジック • 既成の UI ライブラリを魔改造した独自コンポーネント • URLクエリ文字列を直接触って状態を保存するコード • 特定のブラウザ専用のロジック → 具体的なものに密に結合している
28. 具体的なものに密に結合していると負債になりやすい • ライブラリのバージョンアップ、移行で苦しむ • 世の中の環境 （ブラウザ、トレンド） が変わったときに苦しむ • 機能追加、バグ修正するときに抽象化してないと苦しむ
29. 負債になりづらいようにしたい
30. 具体的なものに依存しない コードを書く？
31. 「クリーンアーキテクチャ」？ “優れたアーキテクチャはユースケースを中心にしているため、フレームワーク、 ツール、環境に依存することなく、……” “アーキテクチャはフレームワークに関するものではない（そうあるべきではない）。 アーキテクチャはフレームワークから提供されるものではない。フレームワークは 使用するツールであり、アーキテクチャが従うものではない。” “フレームワークはツールであり、生き方ではない” “Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘. Clean Architecture　達人に学ぶソフトウェアの構造と設計 (Japanese Edition), 2018” 第21章 “叫ぶアーキテクチャ” より
32. OK, OK, じゃあ…… React に依存しないコードを書こう！
33. とはならない (とくにフロントエンドは)
34. ライブラリに依存しないコードを書くのは無理 • React （と Next.js） を使う以上はがっつり乗っかっていくしかない • たとえば UI コンポーネントライブラリを使うなら「そのライブラリの流儀」に 従わないとつらい • ライブラリの流儀に添うことで負債になりやすくなるが開発スピードは上がる
35. ライブラリに依存しないコードを書くのは無理 • React （と Next.js） を使う以上はがっつり乗っかっていくしかない • たとえば UI コンポーネントライブラリを使うなら「そのライブラリの流儀」に 従わないとつらい • ライブラリの流儀に添うことで負債になりやすくなるが開発スピードは上がる このトレードオフのバランスを取りたい
36. KEPPLE DB におけるバランス • 負債を踏み倒せないので、開発スピードに全振りはできない ◦ 長く続けるサービスなので長くメンテできるようにする ◦ リプレースは今回限りにしたい。定期的に作り直す式年遷宮方式にはしない ◦ 返済できない負債を作ってはいけない • 開発スピードが必要なので、負債になりづらさに全振りはできない ◦ リプレース作業の間、通常の機能追加のペースが落ちてしまう
37. フロントエンドの状況の整理
38. （ライブラリ・フレームワークからの） 独立させやすさと開発速度 ※ここでの「独立させやすさ」≒直接依存させないこと、負債になりづらさ
39. ライブラリからの 独立させやすさ ライブラリからの 独立してほしさ ドメインロジック UIの挙動 データフェッチ ディレクトリ構成 フォーマット処理 ルーティング 独立してほしさと独立させやすさ (ざっくり) UIライブラリのス タイリング
40. ライブラリからの 独立させやすさ ライブラリからの 独立してほしさ ドメインロジック UIの挙動 データフェッチ ディレクトリ構成 フォーマット処理 ルーティング 副作用 副作用 副作用 独立してほしさと独立させやすさ (ざっくり) UIライブラリのス タイリング
41. ライブラリからの 独立させやすさ ライブラリからの 独立してほしさ ドメインロジック UIの挙動 データフェッチ ディレクトリ構成 フォーマット処理 ルーティング ユーザーに 見える 独立してほしさと独立させやすさ (ざっくり) UIライブラリのス タイリング
42. ライブラリに依存で 開発速度向上 ドメインロジック UIの挙動 UIライブラリのス タイリング データフェッチ ディレクトリ構成 フォーマット処理 ルーティング ※あくまで KEPPLE DB の場合です ライブラリに依存するメリット (ざっくり)
43. ひとつひとつ見ていく
44. UIの挙動・UIライブラリのスタイリング • 独立させやすさ低、独立してほしさ中〜低 • ライブラリ・環境の破壊的変更が多めなので剥がしやすくしたい • クロスブラウザ対応、アクセシビリティ対応を考えると自作は厳しい • UIライブラリを使うとUIライブラリのデザインシステムに乗っかることになる • ヘッドレスではないUIライブラリは、流儀に従う以外の選択肢がほぼない
45. ルーティング • 独立させやすさ中〜低、独立してほしさ中〜低 • どの Router ライブラリを使っても依存を剥がしづらい • Next.js Pages Router 採用してる時点でがっつり依存するのが確定 • もし方式を変えるなら (ルーティングまわりは) 諦めて作り直したほうが早い
46. データフェッチ • 独立させやすさ中〜低、独立してほしさ中〜低 • 各ライブラリで似た API ではあるが、ラップして吸収しきれるほどではない • 流儀に沿った方がラク • もし剥がしたくなっても機械的に書き換えられる
47. ディレクトリ構成 • 独立させやすさ中〜低、独立してほしさ中〜低 • ファイルシステムベースのルーティングのところ以外は比較的自由にできる
48. ドメインロジックとフォーマット処理 • 各独立させやすさ高〜中、独立してほしさ高〜中 • 副作用のない純粋な関数 • 容易に抽象化できる • フルスクラッチは流石に手間なので、内部的にライブラリを使う
49. 分類を踏まえて KEPPLE DB の方針 • UIライブラリ、ルーティング、データフェッチはライブラリに依存し開発速度をとる • ディレクトリ構成はライブラリに依存しないようにする • ドメインロジック、フォーマット処理はライブラリに直接依存させない • ライブラリの流儀に従いつつ剥がしやすいようにする • 負債の返済をあらかじめ計画に入れておく
50. 具体的に何を工夫したか
51. UIライブラリにどっぷり依存して開発速度を上げる • クロスブラウザ対応、アクセシビリティ対応、デザインシステム構築の 工数削減の対価として、剥がしづらいデメリットは受け入れる • どうせ依存が強いので Button や Text レベルの抽象化はしない (Atomic Design 的に言えば Atom は抽象化しない) • feature を跨ぐコンポーネントの共通化は慎重に
52. UI ライブラリを魔改造しないで済むように進める • 実現したい UI/UX がどうにも実現できない、という状況にしない • 実現したい UI/UX の解像度が低いと魔改造に走りがち。 「前にできてたあれをそのままやりたい！」 リプレースあるある • UI ライブラリのデザインシステムに従う。従うことができるように進める • ビジネス側、デザイナーを巻き込んでライブラリを選定する • Storybook で早くフィードバックをもらい、軌道修正する
53. ルーティングはライブラリにどっぷり依存する • ただし、pages/ 以下のファイルは import した (いくつかの) 関数を 呼び出すだけにしておく • そのうち App Router へ移行するなどの変更に耐えるための処置
54. データフェッチもライブラリにどっぷり依存する • 薄くてシンプルなライブラリがよいなと考えて urql を選んだ • クライアント側は urql の useQuery をそのまま叩いている • その他のところは便利になるようにラップしてたりする
55. ディレクトリ構成はfeatureベースにする • ディレクトリ構成はフレームワークに依存させずユースケースに合わせ、 feature ベースにする • 種類別はフレームワークへの依存度が高い (種類別とは、component, hooks, libs, のよ うなディレクトリの下に機能名のディレクトリがぶら下がる方式を指しています) • ルーティングだけは仕方ないのでフレームワークに従う。
56. ドメインロジックはライブラリに直接依存させない • ドメインロジック、ビジネスロジックはバックに寄せる ◦ フロントとバックの責務の分離の観点でバックに寄せる ◦ バックはクリーンアーキテクチャ的な構造にしやすい • ライブラリを使いつつ副作用のない処理を書いて純粋関数でラップする ◦ 抽象化して剥がしやすく
57. フォーマット処理はライブラリに直接依存させない • フォーマット処理は基本的にフロントに置いている ◦ フロントとバックの責務の分離の観点でフロントに • ライブラリを使いつつ副作用のない処理を書いて純粋関数でラップする ◦ 抽象化して剥がしやすく
58. ライブラリの流儀に添いつつ剥がしやすくする • 副作用がある処理はラップしてもメリットが薄い。 副作用があるということは、たいていライブラリの内部に依存している。 剥がしやすさの観点ではラップしなくてよい • とはいえ使いやすさの観点から多少ラップすることが多かった
59. ライブラリの流儀に添いつつ剥がしやすくする • 容易に剥がせないことがわかっているライブラリは枯れたものを採用 ◦ App Router ではなく Pages Router を採用したのはそのため ◦ （新しいライブラリや新機能を使いたい欲求は別プロダクトで……） • 破壊的変更を頻繁にするライブラリは容易に剥がせるときのみ採用 ◦ Storybook とか
60. ライブラリの流儀に添いつつ剥がしやすくする • トレンドの変化が早そうなライブラリは容易に剥がせるように使う ◦ たとえば Jotai が当てはまる。 グローバルな状態を使いたいところでだけピンポイントで使っている。
61. 負債の返済をあらかじめ計画に入れておく • 「負債の返済が不可欠である」 という認識をビジネス側と共有する • スケジュールに負債の返済を織り込む • KEPPLE DB チームでは毎週金曜日は返済日 • 今回のリプレースでリリース頻度が爆増し、負債の返済の重要性が伝わった
62. まとめ
63. まとめ • 技術的負債になりづらさは開発速度とトレードオフ • KEPPLE DB ではうまく借金して開発速度を上げていく方針をとった • 負債を返しやすい環境づくりが大事