機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

by IkedaNoritaka

Slide 1

Slide 1 text

機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する株式会社ROUTE06 NoritakaIkeda 2025/05/24 TSKaigi2025

Slide 2

Slide 2 text

・NoritakaIkeda ・X(Twitter): @omotidaisukijp ・ROUTE06 Liam開発部・フロントエンド寄りのフルスタック・TSKaigi2024ではLTで登壇自己紹介 2 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 3

Slide 3 text

フロントエンドのコンポーネントどんな粒度で分けていますか 3 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 4

Slide 4 text

どっちが読みやすい？ (複数ロールある、商品詳細ページの例 ) A 4 B はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するロールごとに条件分岐ロールごとにコンポーネント分割

Slide 5

Slide 5 text

どっちが読みやすい？ B 本発表では、 Bを目指したいという話をします 5 厳密な正解があるわけではありませんはじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するロールごとにコンポーネント分割

Slide 6

Slide 6 text

今日話すこと複数ロール、類似の機能を多く含む複雑なシステムの設計に、機能的凝集で立ち向かおう - フラグによる条件付きレンダリングを減らすことで、論理的凝集を回避する - 意味的に違う塊は別コンポーネントにする - 共通化できる塊は思っているより少ない機能的凝集を行うことで、チームのベロシティ、プロダクト品質が向上した - 他のメンバーが書いたコード、自分が過去に書いたコードを読みやすい - 機能中心的に考える際、 APIのスキーマの構造、デザイン、要件を総合的にすり合わせて、各所へフィードバックできる。プロダクトが本来目指すべき姿になっていく 6 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 7

Slide 7 text

コンポーネント分割の観点の例ドメイン・要件的な観点 - ロールごとの分割 - 機能ごとの意味的な分割 - 関連するデータを集約するための分割 UI的な観点 - UIを構成する部品単位での分割 - UIライブラリのラッパーコンポーネント - レイアウト的に再利用可能なコンポーネントその他の観点 - フォームプロバイダーなど、技術的に必要な分割 7 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 8

Slide 8 text

本スライドでは、ドメインや要件の観点の分割の話題にフォーカスしています 8 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 9

Slide 9 text

目次 - 凝集度とは : - 機能的凝集と論理的凝集 - なぜ機能的凝集を目指すべきなのか - 実際のプロジェクトで出会った機能的凝集パターン : - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 9 はじめに機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 10

Slide 10 text

1. 凝集度とはなぜ機能的凝集を目指すのか 10

Slide 11

Slide 11 text

凝集度とはモジュール（関数、クラス、パッケージなど）が単一の目的にどれだけ集中しているか、内部の要素（変数、関数など）がどれだけ密接に関連しているかを表す指標 - 凝集度は高い、低いで表現される - 凝集度の高いモジュールは、堅牢性、信頼性、再利用性、可読性などの点で好ましい偶発的凝集論理的凝集時間的凝集手順的凝集通信的凝集逐次的凝集機能的凝集低い = 避けたい高い = 好ましい 11 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 12

Slide 12 text

本スライドでは論理的凝集と機能的凝集に注目する様々な凝集度の中でも、 UIやコンポーネント設計において頻出する、論理的凝集や機能的凝集に注目 - UI観点のコンポーネント設計では時間的凝集や手順的凝集など上記以外の他の凝集は生まれにくい 12 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する偶発的凝集論理的凝集時間的凝集手順的凝集通信的凝集逐次的凝集機能的凝集低い = 避けたい高い = 好ましい

Slide 13

Slide 13 text

論理的凝集とは論理的凝集：似たような処理をフラグや条件で切り替えて 1つにまとめている状態（避けたい） - コンポーネントに条件分岐が多く点在するようになり、可読性が落ち、保守のコストが増加する - 共通化としてやりがち 13 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するロールごとの機能を追加商品詳細画面ロールごとに条件分岐

Slide 14

Slide 14 text

機能的凝集とは機能的凝集：モジュール全体が単一の明確な目的のために構成されている状態（理想的な形） - コンポーネントの責務が明確になりがち - 共通化したい余地が残る 14 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するロールごとの機能を追加商品詳細画面ロールごとにコンポーネント分割

Slide 15

Slide 15 text

機能的凝集で共通化したい時には共通化をしたいなら、それぞれのロールで共通する部分を、意味ある単位で切り出すと良い 15 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する共通化

Slide 16

Slide 16 text

機能的凝集と論理的凝集 16 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する機能的凝集論理的凝集機能的凝集は責務ごとにコンポーネントを分け、論理的凝集は条件分岐で責務を切り替える。比べると、、

Slide 17

Slide 17 text

なぜ論理的凝集を避けるのかコードが大きくなるにつれて、条件分岐が増え、コードの複雑さが増していく人間が書く文章 (要件定義書など )でも、細部に場合分けが多い文章は読みにくいはず「似ているから共通化したい」「今は簡単な分岐だけだ」と思ったとしても、将来的にさらに条件を追加したくなるような場合は多い 17 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する条件分岐がコードの中に点在

Slide 18

Slide 18 text

なぜ論理的凝集を避けるのか 18 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する 🚩開発初期の判断（ありがちな思考） : 「購入者と出品者で商品詳細の UI、ほとんど同じだし、ひとつのProductDetailコンポーネントで共通化しよう」「今は価格と在庫の表示を切り替えるだけだし、 role === 'buyer'の条件で分ければ十分」 🧨 時間が経ってから発生する現実 : 「購入者のモバイルの画面ではレビューを非表示にして」「出品者の画面ではドラフト状態の時だけ公開ボタン出して」「在庫がない商品は購入者にも出品者にも警告を出す。ただしアドミンには出さない」「管理者用にも同じコンポーネント使って、 IDと出品者情報表示して」「購入者がログインしてないときは購入ボタンを押せなくして」条件分岐がコードの中に点在

Slide 19

Slide 19 text

なぜ機能的凝集を目指すのか ✨機能の修正や追加に耐えやすい - コードの修正が他の機能まで影響しにくい - 今修正したい、関心があるコードのみを読むことができる - 機能的凝集をしておけば、追加するコードも機能的凝集しやすくなる 🔧 要件とコードが一致しているか確認しやすい - 要件定義書は機能単位で書かれているはずなので対応づけて読みやすい - 別の機能を開発しているメンバー、デザインエンジニアと意思疎通がとりやすい 19 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 20

Slide 20 text

🙋確かに良さそう！機能的凝集をしていきます！ 20 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 21

Slide 21 text

🤔 ここ、条件分岐を入れざるを得ない気がする 🤔 機能的凝集をしようとすると分割の粒度が変になるな 21 1. 凝集度とは機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 22

Slide 22 text

2. 実際のプロジェクトで出会った機能的凝集パターンコンポーネント分割の落とし穴とケーススタディ 22

Slide 23

Slide 23 text

登壇者の参加したプロジェクト背景 DXを推進したい分野の複雑な業務ドメイン - 複数ロール / 管理者ロール - ロールによって異なる業務フロー・状態遷移がある - ロール間で相互作用がある操作がある - ロールごとに異なる操作権限・閲覧権限がある - 多岐にわたる業務フロー前提 - フロントエンドチームは 5~7名程度 - 要件定義やデザイン、 APIスキーマは別チームが策定 - React + Vite + GraphQL(型付きAPIスキーマ) - 参考のADR: https://tech.route06.co.jp/entry/2023/08/08/115253 具体的なドメインは公開できないため、以後、 ECドメインを参考にサンプルコードを提示します 23 機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する 2. 実際のプロジェクトで出会った機能的凝集パターン

Slide 24

Slide 24 text

実際のプロジェクトで出会った、状況別、機能的凝集パターン私たちのプロジェクトでよく出会ったり、設計的にトレードオフが強かった部分にフォーカスして、事例を共有します。それぞれの状況ごとに、私たちが行った判断を共有します。 - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 24 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 25

Slide 25 text

実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Case1: ログインユーザのロールごとに類似画面を表示する - Case2: 新規作成画面と編集画面 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 25 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 26

Slide 26 text

Pattern1: ルーティングで分岐できる場合 26 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するルーティングから機能ごとの分岐ができる場合、そのまま分岐すると、コンポーネント側で条件分岐を持つ必要がなくなって嬉しい

Slide 27

Slide 27 text

Case1: ログインユーザのロールごとに類似画面を表示するログインユーザのロールごとにルーティングで分岐している場合の例類似箇所の共通化の話は Pattern3で説明します 27 Pattern1: ルーティングで分岐できる場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するルーティングからページコンポーネントを呼び出す

Slide 28

Slide 28 text

Case2: 新規作成画面と編集画面なんだか似てる 28 機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する Pattern1: ルーティングで分岐できる場合

Slide 29

Slide 29 text

Case2: 新規作成画面と編集画面以下のような違いがある 29 機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する Pattern1: ルーティングで分岐できる場合タイトルが違う初期値が入っている文字と押下した時の関数が違う

Slide 30

Slide 30 text

Case2: 新規作成画面と編集画面スキーマが同じでいいなら、フォームコンポーネントは統一できるタイトル、送信のための関数や defaultValuesは、 Page側で責務を持つ設計だとシンプルで保守性が高い 30 機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するルーティングからページコンポーネントを呼び出す Pattern1: ルーティングで分岐できる場合

Slide 31

Slide 31 text

実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Case3: ディレクトリシステム - Case4: 通知機能 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 31 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 32

Slide 32 text

Pattern2: 分岐がコンポーネント内から排除出来ない 32 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する APIなどから取得したデータやその型を元に分岐しなければならない場合、 Pattarn1と違い、データ取得箇所から UI表示までのどこかに条件分岐が発生する → 論理的凝集せざるを得ない？

Slide 33

Slide 33 text

Case3: ディレクトリシステム GoogleDriveみたいなシステム 33 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 34

Slide 34 text

Case3: ディレクトリシステムディレクトリシステムを作る場合、テーブルで類似アイテムを出し分ける必要がある 34 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するアイコンが違うファイルに対する操作がが違うレコードを押下した時の挙動が違う

Slide 35

Slide 35 text

Case3: ディレクトリシステム論理的凝集で実装すると、アイコン、押下時に発火する関数、ファイル操作のアイコンと関数のそれぞれで条件分岐が発生する 35 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する条件分岐がコードの中に点在

Slide 36

Slide 36 text

Case3: ディレクトリシステムどこで条件分岐を行うか？ - 出しわけの責務をコンポーネントの親になるコンポーネントに移譲する - 出し分けるための責務を持ったコンポーネントを作る - もしくはList側でmapの中で出し分ける 36 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 37

Slide 37 text

Case4: 通知機能通知はサイトを横断的にトリガーされるため、様々な UIデザインパターンが存在しやすい UI的に似ているが、以下の点で違いがある - 表示するラベルに入っているデータの種類・数 - 通知を押下して遷移する先の画面 37 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する想定する通知の型

Slide 38

Slide 38 text

Case4: 通知機能定義されている APIのスキーマ型を ts-patternで出し分けると機能的凝集になりやすい .exhaustive()を用いることで、型の抜け漏れを防げる追加開発のタイミングでも、特定の通知が飛ばないようなエラーを未然に防げる 38 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 39

Slide 39 text

実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 39 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 40

Slide 40 text

Pattern3: 共通化したいなという気持ちが芽生えた時共通化したいなと思う、エンジニア的な嗅覚・直感 - コードを局所的に見て、「ここの実装似ているかも？」「過去に似た実装をした記憶がある」「共通化した先の幸せな未来が見える」機能的な関連性を正しく評価したい - 要件、デザイン、 APIのスキーマの型からヒントを集め、総合的に判断する - 要件、デザイン、 APIのスキーマは、実装がない中、様々な仮定のなかで作成されているものなので、それらの辻褄をしっかり合わせる作業になる 40 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 41

Slide 41 text

そもそも分割するに値するか、以下の要素から判断する分割したい箇所の実装量、実装の複雑さ - ループ処理、状態管理、条件分岐などが入ってくると分割する価値があるかもしれない分割したい箇所が、 Figmaでグルーピングもしくはコンポーネント化されているか - 共通化したいからといって、意味的に一塊のものから無理に切り出していないか分割したい箇所が、 APIのスキーマのオブジェクト型の塊と一致しているか - オブジェクト型でまとまっているものは一つの意味の塊として見出しやすいチーム内の (形式的/暗黙的な)合意に従う - コード規約 - 実際のコードの分割粒度 41 Pattern3: 共通化したいなという気持ちが芽生えた時機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 42

Slide 42 text

共通化できる時とはどんな時か (実装も、Figma上も似通っている前提 ) 要件定義的にも同じと言えるか - 購入者視点の「購入履歴画面」と、管理者視点の「注文管理画面」だと、意味的に同じだと言いにくい - その中のに通った UIを共通化していいか十分に注意を払うべき APIのスキーマのオブジェクト型的に同じかどうか - Buyerオブジェクトの中の Userオブジェクトと、 SellerUserオブジェクトは同じだと言いにくい - 十分注意して共通化の判断をするか、 APIスキーマ側で Sellerオブジェクトの中の Userオブジェクトみたいな実装にできないか相談 42 Pattern3: 共通化したいなという気持ちが芽生えた時機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 43

Slide 43 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てる GoogleDriveみたいなシステム 43 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 44

Slide 44 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てるディレクトリシステムを作る場合、テーブルで類似アイテムを出し分ける必要がある 44 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するアイコンが違うファイルに対する操作がが違うレコードを押下した時の挙動が違う

Slide 45

Slide 45 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てる GoogleDriveみたいなシステム 45 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するレコード単位で機能的凝集できそう

Slide 46

Slide 46 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てる GoogleDriveみたいなシステム 46 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するここら辺同じ感じがするな

Slide 47

Slide 47 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てる GoogleDriveみたいなシステム 47 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するでも、ここってデザイン的に、 1カラムでまとめないといけない気がする APIスキーマも、 nameとicon typeって並列に並んでいる →カラムのコンポーネントの中で出し分けるか

Slide 48

Slide 48 text

(余裕があれば ) Case3: ディレクトリシステムの共通化の目処を立てる GoogleDriveみたいなシステム 48 Pattern2: 分岐がコンポーネント内から排除出来ない場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割するレコード単位では、レコードを押した時の挙動と、ファイルに対する操作を機能的分割したら良さそうレコードを押下した時の挙動が違うファイルに対する操作がが違うここは、組み合わせのバリエーションが多いのと使い回しの箇所も多くないので共通化しないでおくか

Slide 49

Slide 49 text

実際のプロジェクトで出会った、状況別、機能的凝集パターン - Pattern1: ルーティングで分岐できる場合 - Pattern2: 分岐がコンポーネント内から排除出来ない場合 - Pattern3: 共通化したいなという気持ちが湧き出てきた場合 - Pattern4: コンポーネント分割単位との競合する場合 - Case5: 商品詳細画面 : 差分が小さい類似機能 49 2. 実際のプロジェクトで出会った機能的凝集パターン機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 50

Slide 50 text

Case5: 商品詳細画面 : 差分が小さい類似機能差分が非常に小さい場合、責務がかなり薄いコンポーネントができてしまう - チームのコード規約にもよるが、責務が薄すぎるコンポーネントは可読性を落とすため、排除したい - BuyerProductPageは一行のUIを追加するためのコードと、 BigProductDetail の重たい責務と並列に存在する構造は、不自然でアンバランス 50 Pattern4: コンポーネント分割単位との競合する場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 51

Slide 51 text

Case5: 商品詳細画面 : 差分が小さい類似機能ロール名や Typeのような意味的な命名のフラグではなく、機能を表示するかしないかの命名のフラグだと、分岐があっても機能的凝集に近い形にしやすいただ大量にフラグを渡すと可読性を落とすので、小さい箇所で 1~2個が限度 51 Pattern4: コンポーネント分割単位との競合する場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 52

Slide 52 text

Case5: 商品詳細画面 : 差分が小さい類似機能 ReactNodeをプロップスとして渡す、もしくは React.children方法を渡す方法 UIのレイアウトの手法としてよく用いられる。機能ごとの差分を親コンポーネントに集約したいときに使用。子コンポーネント側だけを見て、何が渡されているのかわかりにくくなるため、使用頻度は低い。命名はもっと具体的に、機能の名前にするべき。 52 Pattern4: コンポーネント分割単位との競合する場合機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 53

Slide 53 text

やってよかったことチームのベロシティが安定した - 別のメンバーが担当していた機能のコードが読みやすく、誰でもどの機能の開発にもスムーズに入れる状態 - pjの進め方として、タスクを細かくし、早く自分のタスクが終わった人は作業量が多い機能に入っていく形式をとっていたので、マッチしたコードと要件の対応がわかりやすいため、オンボーディングしやすいリリース前の QAやテストなどでバグが報告された時、数ヶ月前に実装した自分のコードのキャッチアップ速度が速くなる 53 まとめ機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する

Slide 54

Slide 54 text

今日話すこと複数ロール、類似の機能を多く含む複雑なシステムの設計に、機能的凝集で立ち向かおう - フラグによる条件付きレンダリングを減らすことで、論理的凝集を回避する - 意味的に違う塊は別コンポーネントにする - 共通化できる塊は思っているより少ない機能的凝集を行うことで、チームのベロシティ、プロダクト品質が向上した - 他のメンバーが書いたコード、自分が過去に書いたコードを読みやすい - 機能中心的に考える際、 APIのスキーマの構造、デザイン、要件を総合的にすり合わせて、各所へフィードバックできる。プロダクトが本来目指すべき姿になっていく 54 まとめ機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する