@k2works/claude-code-booster 3.0.0 → 3.1.0

package/lib/assets/docs/article/getting-start-tdd/elixir/05-package-management-and-static-analysis.md

@@ -0,0 +1,88 @@
+# 第 5 章: パッケージ管理と静的解析
+
+## 5.1 はじめに
+
+この章では、Elixir の依存管理とコード品質チェックを扱います。`Mix`、`Hex`、`Credo`、`mix format`、複雑度チェックを組み合わせ、TDD の継続速度と品質を両立します。
+
+## 5.2 Mix による依存管理
+
+Elixir の依存関係は `mix.exs` の `deps/0` で定義します。
+
+```elixir
+# apps/elixir/mix.exs
+
+defp deps do
+  [
+    {:credo, "~> 1.7", only: [:dev, :test], runtime: false}
+  ]
+end
+```
+
+依存追加後は `mix deps.get` で取得します。
+
+```bash
+cd apps/elixir
+mix deps.get
+```
+
+`only: [:dev, :test]` を使うと、開発時だけ必要なツール依存を本番実行から分離できます。
+
+## 5.3 Hex パッケージマネージャ
+
+`Hex` は Elixir の公式パッケージレジストリです。`mix deps.get` は `Hex` から依存を解決し、`mix.lock` にバージョンを固定します。
+
+日常的に使う操作は次のとおりです。
+
+```bash
+mix deps.get        # 依存取得
+mix deps.update all # 依存更新
+mix deps.tree       # 依存ツリー確認
+```
+
+チーム開発では `mix.lock` をコミットし、依存の再現性を確保します。
+
+## 5.4 Credo による静的解析
+
+`Credo` は Elixir の静的解析ツールです。本プロジェクトでは厳格モードを使います。
+
+```bash
+mix credo --strict
+```
+
+`--strict` は警告を増やし、早い段階で設計上の問題や可読性低下を検出できます。`apps/elixir/Makefile` でも `lint` タスクとして定義されています。
+
+## 5.5 mix format と .formatter.exs
+
+コードフォーマットは `mix format` で統一します。
+
+```bash
+mix format
+mix format --check-formatted
+```
+
+`apps/elixir/.formatter.exs` では対象ファイルを次のように設定しています。
+
+```elixir
+[
+  inputs: ["{mix,.formatter}.exs", "{config,lib,test}/**/*.{ex,exs}"]
+]
+```
+
+CI では `--check-formatted` を使い、未整形コードの混入を防ぎます。
+
+## 5.6 コード複雑度チェック
+
+本プロジェクトでは `scripts/complexity.sh` で循環複雑度を簡易計測します。
+
+```bash
+bash scripts/complexity.sh --threshold 10 lib
+```
+
+- `--threshold 10`: 閾値を 10 に設定
+- `lib`: チェック対象ディレクトリ
+
+このチェックを `make complexity` や CI に組み込むことで、関数の肥大化を継続的に抑制できます。
+
+## 5.7 まとめ
+
+この章では、`mix.exs` の `deps` を起点にした依存管理、`Hex` によるパッケージ解決、`Credo` と `mix format` による静的品質担保、`scripts/complexity.sh` による複雑度管理を確認しました。次章では、これらを `Makefile` と CI/CD に統合します。

package/lib/assets/docs/article/getting-start-tdd/elixir/06-task-runner-and-ci-cd.md

@@ -0,0 +1,71 @@
+# 第 6 章: タスクランナーと CI/CD
+
+## 6.1 はじめに
+
+この章では、ローカル開発と CI を同じ実行基盤でそろえる方法を扱います。Nix で環境差分を吸収し、`Makefile` と GitHub Actions で品質チェックを自動化します。
+
+## 6.2 Nix 開発環境による環境管理
+
+本プロジェクトの Elixir 開発環境は Nix で提供されています。次のコマンドで同一ツールチェーンに入れます。
+
+```bash
+nix develop .#elixir
+```
+
+この方式により、OS 差分やローカルの手動セットアップ差分を最小化できます。CI でも同じ `nix develop .#elixir` を使うため、ローカル再現性が高くなります。
+
+## 6.3 Makefile でのタスク管理
+
+`apps/elixir/Makefile` には主要タスクが定義されています。
+
+- `make test`: `mix test`
+- `make fmt`: `mix format`
+- `make fmt-check`: `mix format --check-formatted`
+- `make lint`: `mix credo --strict`
+- `make complexity`: `bash scripts/complexity.sh --threshold 10 lib`
+- `make check`: `fmt-check` + `lint` + `complexity` + `test`
+
+開発中は `make check` を最終ゲートにすると、レビュー前の品質をそろえやすくなります。
+
+## 6.4 mix の監視実行と高速テスト
+
+Elixir ではファイル更新検知に Linux 固有の `inotify-tools` は不要です。継続実行したい場合は監視実行を利用します。
+
+```bash
+mix test --watch
+```
+
+また、変更影響のあるテストだけを優先して回すには `--stale` が有効です。
+
+```bash
+mix test --stale
+```
+
+- `--watch`: 保存ごとに再実行
+- `--stale`: 変更があったモジュールに関連するテスト中心で実行
+
+日常開発は `mix test --stale`、節目では `mix test` や `make check` を回す運用が実践的です。
+
+## 6.5 GitHub Actions での Nix ベース CI/CD
+
+Elixir 用 CI は最初から Nix ベースで構築されています。`.github/workflows/elixir-ci.yml` では次の流れを実行します。
+
+1. `actions/checkout@v4`
+2. `cachix/install-nix-action@v30` で Nix を導入
+3. `nix develop .#elixir --command ...` で依存取得・Format・Lint・複雑度・テストを実行
+
+例:
+
+```yaml
+- name: Install Nix
+  uses: cachix/install-nix-action@v30
+
+- name: Run tests
+  run: nix develop .#elixir --command bash -c "cd apps/elixir && mix test"
+```
+
+重要なのは、ローカルと CI が同じ `nix develop` を起点にしている点です。これにより「ローカルでは通るが CI で失敗する」を減らせます。
+
+## 6.6 まとめ
+
+この章では、`nix develop .#elixir` による環境統一、`Makefile` によるタスク標準化、`mix test --watch` / `mix test --stale` の使い分け、GitHub Actions の Nix ベース CI を確認しました。これで TDD の反復を壊さない自動化基盤が整います。

package/lib/assets/docs/article/getting-start-tdd/elixir/07-structs-and-protocols.md

@@ -0,0 +1,110 @@
+# 第 7 章: 構造体とプロトコルによるポリモーフィズム
+
+## 7.1 はじめに
+
+この章では、`defstruct` と `defprotocol` を使って、Elixir で型ごとに振る舞いを切り替える方法を学びます。FizzBuzz の値オブジェクトを導入し、`Type01`、`Type02`、`Type03` が同じインターフェース `generate/1` を実装する形でポリモーフィズムを実現します。
+
+## 7.2 defstruct で値オブジェクトを定義する
+
+FizzBuzz の入力値を表す値オブジェクト `FizzBuzz.Model.Value` を定義します。`@enforce_keys` で必須フィールドを宣言すると、不完全な構造体生成を防げます。
+
+```elixir
+defmodule FizzBuzz.Model.Value do
+  @enforce_keys [:number]
+  defstruct [:number]
+
+  @type t :: %__MODULE__{
+          number: pos_integer()
+        }
+end
+```
+
+`@enforce_keys [:number]` により、`%FizzBuzz.Model.Value{}` のような生成は実行時エラーになり、`number` の設定漏れを早期に検出できます。
+
+## 7.3 defprotocol で共通インターフェースを定義する
+
+次に、生成処理の共通契約として `Generatable` プロトコルを定義します。
+
+```elixir
+defprotocol FizzBuzz.Generatable do
+  @spec generate(t()) :: String.t()
+  def generate(value)
+end
+```
+
+プロトコルは「どの型であっても `generate/1` を呼べる」という抽象化を提供します。実際の処理は各構造体の `defimpl` で分岐します。
+
+## 7.4 defimpl で Type01 / Type02 / Type03 を実装する
+
+`Type01`、`Type02`、`Type03` は、それぞれ通常数値、3 の倍数、5 の倍数を表す構造体とします。
+
+```elixir
+defmodule FizzBuzz.Model.Type01 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defmodule FizzBuzz.Model.Type02 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defmodule FizzBuzz.Model.Type03 do
+  @enforce_keys [:value]
+  defstruct [:value]
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type01 do
+  def generate(%FizzBuzz.Model.Type01{value: value}), do: Integer.to_string(value.number)
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type02 do
+  def generate(%FizzBuzz.Model.Type02{}), do: "Fizz"
+end
+
+defimpl FizzBuzz.Generatable, for: FizzBuzz.Model.Type03 do
+  def generate(%FizzBuzz.Model.Type03{}), do: "Buzz"
+end
+```
+
+この設計では、呼び出し側は具体型を意識せず、`FizzBuzz.Generatable.generate/1` だけを呼べばよくなります。
+
+## 7.5 ExUnit でプロトコル実装を検証する
+
+プロトコルの振る舞いは ExUnit で確認できます。
+
+```elixir
+defmodule FizzBuzz.GeneratableTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Generatable
+  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
+
+  test "Type01 は数値文字列を返す" do
+    value = %Value{number: 1}
+    assert Generatable.generate(%Type01{value: value}) == "1"
+  end
+
+  test "Type02 は Fizz を返す" do
+    value = %Value{number: 3}
+    assert Generatable.generate(%Type02{value: value}) == "Fizz"
+  end
+
+  test "Type03 は Buzz を返す" do
+    value = %Value{number: 5}
+    assert Generatable.generate(%Type03{value: value}) == "Buzz"
+  end
+
+  test "Value は number が必須" do
+    assert_raise ArgumentError, fn ->
+      struct!(Value, %{})
+    end
+  end
+end
+```
+
+`struct!/2` を使うと、`@enforce_keys` の違反をテストで明示的に確認できます。
+
+## 7.6 まとめ
+
+この章では、`defstruct` と `@enforce_keys` で値オブジェクトを定義し、`defprotocol` / `defimpl` で型ごとに `generate/1` を実装しました。Elixir では継承ではなく、プロトコルでポリモーフィズムを組み立てるのが実践的です。

package/lib/assets/docs/article/getting-start-tdd/elixir/08-pattern-matching-and-guards.md

@@ -0,0 +1,108 @@
+# 第 8 章: パターンマッチとガード節
+
+## 8.1 はじめに
+
+この章では、Elixir の分岐を読みやすく保つために、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分けを整理します。あわせて、タグ付きタプル `{:ok, value}` / `{:error, reason}` による結果表現も確認します。
+
+## 8.2 関数頭部でのパターンマッチ
+
+Elixir では値ごとの分岐を関数定義に直接書けます。
+
+```elixir
+defmodule FizzBuzz.Factory do
+  alias FizzBuzz.Model.{Type01, Type02, Type03, Value}
+
+  def create(1), do: %Type01{value: %Value{number: 1}}
+  def create(2), do: %Type01{value: %Value{number: 2}}
+  def create(3), do: %Type02{value: %Value{number: 3}}
+  def create(5), do: %Type03{value: %Value{number: 5}}
+  def create(_), do: :unsupported
+end
+```
+
+`def create(1)`、`def create(2)`、`def create(_)` のように書くと、`if` より宣言的で見通しがよくなります。
+
+## 8.3 ガード節で入力条件を制約する
+
+パターンだけで不足する条件は `when` を使います。
+
+```elixir
+defmodule FizzBuzz.Validator do
+  def validate(number) when is_integer(number) and number > 0, do: {:ok, number}
+  def validate(number) when is_integer(number), do: {:error, :non_positive}
+  def validate(_), do: {:error, :not_integer}
+end
+```
+
+`when is_integer(number) and number > 0` により、正常系の条件を関数シグネチャ近くで明示できます。
+
+## 8.4 case 式と cond 式の使い分け
+
+`case` は「値の形」を分岐するときに向いており、`cond` は「複数の真偽条件」を評価するときに向いています。
+
+```elixir
+defmodule FizzBuzz.Renderer do
+  def from_result(result) do
+    case result do
+      {:ok, value} -> "ok: #{value}"
+      {:error, reason} -> "error: #{reason}"
+    end
+  end
+
+  def classify(number) do
+    cond do
+      rem(number, 15) == 0 -> :fizz_buzz
+      rem(number, 3) == 0 -> :fizz
+      rem(number, 5) == 0 -> :buzz
+      true -> :number
+    end
+  end
+end
+```
+
+- `case`: `{:ok, value}` のようなタグ付きデータを分解する。
+- `cond`: `rem/2` の結果など条件式を上から順に判定する。
+
+## 8.5 ExUnit で分岐をテストする
+
+分岐ロジックは仕様が崩れやすいため、タグ付きタプルまで含めてテストします。
+
+```elixir
+defmodule FizzBuzz.PatternMatchingTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Factory
+  alias FizzBuzz.Renderer
+  alias FizzBuzz.Validator
+  alias FizzBuzz.Model.Type02
+
+  test "create/1 は 3 を Type02 として生成する" do
+    assert %Type02{} = Factory.create(3)
+  end
+
+  test "validate/1 は正の整数を {:ok, value} で返す" do
+    assert Validator.validate(10) == {:ok, 10}
+  end
+
+  test "validate/1 は不正な入力を {:error, reason} で返す" do
+    assert Validator.validate(0) == {:error, :non_positive}
+    assert Validator.validate("10") == {:error, :not_integer}
+  end
+
+  test "from_result/1 はタグ付きタプルを文字列化する" do
+    assert Renderer.from_result({:ok, "Fizz"}) == "ok: Fizz"
+    assert Renderer.from_result({:error, :not_integer}) == "error: not_integer"
+  end
+
+  test "classify/1 は cond で優先順位どおりに判定する" do
+    assert Renderer.classify(15) == :fizz_buzz
+    assert Renderer.classify(6) == :fizz
+    assert Renderer.classify(10) == :buzz
+    assert Renderer.classify(7) == :number
+  end
+end
+```
+
+## 8.6 まとめ
+
+この章では、関数頭部のパターンマッチ、`when` ガード節、`case` と `cond` の使い分け、タグ付きタプルによる結果表現を確認しました。これらを組み合わせると、分岐が増えても読みやすさと安全性を維持できます。

package/lib/assets/docs/article/getting-start-tdd/elixir/09-module-design-and-behaviours.md

@@ -0,0 +1,104 @@
+# 第 9 章: モジュール設計とビヘイビア
+
+## 9.1 はじめに
+
+この章では、モジュールの責務分割を保ちながら拡張しやすい構成を作るために、モジュールの入れ子、`@behaviour` / `@callback`、`alias` を使った設計を扱います。FizzBuzz のコマンド層を例に、共通インターフェースを実装する形へ整理します。
+
+## 9.2 モジュールの入れ子で責務を表現する
+
+Elixir はファイル階層とは独立して、名前空間で責務を整理できます。たとえば `FizzBuzz.Command.ValueCommand` は「単一値を扱うコマンド」を明確に示します。
+
+```elixir
+defmodule FizzBuzz.Command.ValueCommand do
+  def run(number), do: Integer.to_string(number)
+end
+```
+
+`FizzBuzz.Command` 配下に `ValueCommand` と `ListCommand` を置くと、同じ関心事のモジュール群を把握しやすくなります。
+
+## 9.3 @behaviour と @callback でインターフェースを定義する
+
+まずはコマンド共通の契約を `FizzBuzz.Command` ビヘイビアとして定義します。
+
+```elixir
+defmodule FizzBuzz.Command do
+  @callback run(input :: term()) :: {:ok, term()} | {:error, atom()}
+end
+```
+
+この `@callback` により、実装モジュールは `run/1` を提供する必要があります。未実装の場合、コンパイル時に警告が出るため、設計の抜け漏れを防げます。
+
+## 9.4 ValueCommand と ListCommand でビヘイビアを実装する
+
+`@behaviour FizzBuzz.Command` を指定し、`run/1` を実装します。`alias` を使ってモジュール参照を簡略化します。
+
+```elixir
+defmodule FizzBuzz.Command.ValueCommand do
+  @behaviour FizzBuzz.Command
+
+  alias FizzBuzz.FizzBuzzService
+
+  @impl true
+  def run(number) when is_integer(number) and number > 0 do
+    {:ok, FizzBuzzService.generate(number)}
+  end
+
+  @impl true
+  def run(_), do: {:error, :invalid_number}
+end
+
+defmodule FizzBuzz.Command.ListCommand do
+  @behaviour FizzBuzz.Command
+
+  alias FizzBuzz.FizzBuzzService
+
+  @impl true
+  def run(limit) when is_integer(limit) and limit > 0 do
+    values =
+      1..limit
+      |> Enum.map(&FizzBuzzService.generate/1)
+
+    {:ok, values}
+  end
+
+  @impl true
+  def run(_), do: {:error, :invalid_limit}
+end
+```
+
+`alias FizzBuzz.FizzBuzzService` を使うことで、`FizzBuzz.FizzBuzzService.generate/1` を `FizzBuzzService.generate/1` と短く書けます。
+
+## 9.5 ExUnit でビヘイビア実装を検証する
+
+各コマンドが同じ契約で動くことを ExUnit で確認します。
+
+```elixir
+defmodule FizzBuzz.CommandTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.Command.{ListCommand, ValueCommand}
+
+  test "ValueCommand は単一値を処理する" do
+    assert ValueCommand.run(3) == {:ok, "Fizz"}
+  end
+
+  test "ValueCommand は不正値でエラーを返す" do
+    assert ValueCommand.run(0) == {:error, :invalid_number}
+    assert ValueCommand.run("3") == {:error, :invalid_number}
+  end
+
+  test "ListCommand は 1..limit の結果一覧を返す" do
+    assert ListCommand.run(5) == {:ok, ["1", "2", "Fizz", "4", "Buzz"]}
+  end
+
+  test "ListCommand は不正値でエラーを返す" do
+    assert ListCommand.run(-1) == {:error, :invalid_limit}
+  end
+end
+```
+
+`ValueCommand` と `ListCommand` は入出力対象が異なっても、同じ `run/1` 契約を守るため、呼び出し側の扱いを統一できます。
+
+## 9.6 まとめ
+
+この章では、`FizzBuzz.Command.ValueCommand` のようなモジュール入れ子で責務を整理し、`@behaviour` / `@callback` で契約を固定し、`alias` で記述を簡潔にする方法を確認しました。ビヘイビア中心の設計により、機能追加時も既存コードへの影響を局所化できます。

package/lib/assets/docs/article/getting-start-tdd/elixir/10-higher-order-functions-and-pipeline.md

@@ -0,0 +1,178 @@
+# 第 10 章: 高階関数とパイプライン演算子
+
+## 10.1 はじめに
+
+この章では、Elixir の高階関数を使って、データ変換を宣言的に記述する方法を学びます。`Enum.map`、`Enum.filter`、`Enum.reduce`、無名関数、`|>` パイプライン演算子を組み合わせ、FizzBuzz の実装を拡張します。
+
+## 10.2 高階関数の基本: Enum.map / Enum.filter / Enum.reduce
+
+高階関数は、関数を引数として受け取る関数です。Elixir では `Enum` モジュールが代表例です。
+
+```elixir
+defmodule FizzBuzz.Functional do
+  def generate(number) when rem(number, 15) == 0, do: "FizzBuzz"
+  def generate(number) when rem(number, 3) == 0, do: "Fizz"
+  def generate(number) when rem(number, 5) == 0, do: "Buzz"
+  def generate(number), do: Integer.to_string(number)
+
+  def generate_list(limit) do
+    1..limit
+    |> Enum.map(&generate/1)
+  end
+
+  def count_fizzbuzz(limit) do
+    1..limit
+    |> Enum.map(&generate/1)
+    |> Enum.filter(&(&1 in ["Fizz", "Buzz", "FizzBuzz"]))
+    |> Enum.count()
+  end
+
+  def summary(limit) do
+    1..limit
+    |> Enum.map(&generate/1)
+    |> Enum.reduce(%{fizz: 0, buzz: 0, fizzbuzz: 0, number: 0}, fn value, acc ->
+      case value do
+        "Fizz" -> %{acc | fizz: acc.fizz + 1}
+        "Buzz" -> %{acc | buzz: acc.buzz + 1}
+        "FizzBuzz" -> %{acc | fizzbuzz: acc.fizzbuzz + 1}
+        _ -> %{acc | number: acc.number + 1}
+      end
+    end)
+  end
+end
+```
+
+## 10.3 無名関数: fn と & キャプチャ演算子
+
+Elixir には 2 つの無名関数の書き方があります。
+
+```elixir
+defmodule FizzBuzz.Anonymous do
+  def multiply_all(numbers, factor) do
+    Enum.map(numbers, fn n -> n * factor end)
+  end
+
+  def square_all(numbers) do
+    Enum.map(numbers, &(&1 * &1))
+  end
+
+  def stringify(numbers) do
+    Enum.map(numbers, &Integer.to_string/1)
+  end
+end
+```
+
+- `fn n -> ... end` は複雑なロジックに向いています。
+- `&(&1 * &1)` のようなキャプチャ演算子は短く書けます。
+
+## 10.4 パイプライン演算子 |> で関数チェーンを書く
+
+`|>` は左側の値を右側関数の第 1 引数に渡します。処理の流れを上から下に読めるため、可読性が上がります。
+
+```elixir
+defmodule FizzBuzz.Pipeline do
+  alias FizzBuzz.Functional
+
+  def report(limit) do
+    1..limit
+    |> Enum.map(&Functional.generate/1)
+    |> Enum.filter(&(&1 != "FizzBuzz"))
+    |> Enum.join(",")
+  end
+end
+```
+
+## 10.5 generate_with/2 でカスタムルール関数を受け取る
+
+高階関数を使うと、ルールを外部から注入できます。`generate_with/2` は「数値」と「ルール関数」を受け取ります。
+
+```elixir
+defmodule FizzBuzz.CustomRule do
+  def generate_with(number, rule_fn) when is_function(rule_fn, 1) do
+    case rule_fn.(number) do
+      nil -> Integer.to_string(number)
+      value -> value
+    end
+  end
+
+  def generate_with(number, rule_fns) when is_list(rule_fns) do
+    result =
+      Enum.reduce_while(rule_fns, nil, fn rule_fn, _acc ->
+        case rule_fn.(number) do
+          nil -> {:cont, nil}
+          value -> {:halt, value}
+        end
+      end)
+
+    result || Integer.to_string(number)
+  end
+end
+```
+
+## 10.6 transform/2 と filter/2 で汎用化する
+
+FizzBuzz 専用処理を汎用関数に切り出すと、再利用しやすくなります。
+
+```elixir
+defmodule FizzBuzz.Collection do
+  def transform(values, mapper) when is_function(mapper, 1) do
+    Enum.map(values, mapper)
+  end
+
+  def filter(values, predicate) when is_function(predicate, 1) do
+    Enum.filter(values, predicate)
+  end
+end
+```
+
+## 10.7 ExUnit で高階関数を検証する
+
+```elixir
+defmodule FizzBuzz.HigherOrderFunctionsTest do
+  use ExUnit.Case, async: true
+
+  alias FizzBuzz.{Collection, CustomRule, Functional}
+
+  test "Enum.map で FizzBuzz の一覧を生成できる" do
+    assert Functional.generate_list(5) == ["1", "2", "Fizz", "4", "Buzz"]
+  end
+
+  test "Enum.filter と Enum.count で Fizz/Buzz 系だけ数えられる" do
+    assert Functional.count_fizzbuzz(15) == 7
+  end
+
+  test "Enum.reduce で種別ごとの集計ができる" do
+    assert Functional.summary(15) == %{fizz: 4, buzz: 2, fizzbuzz: 1, number: 8}
+  end
+
+  test "generate_with/2 は単一ルール関数を受け取れる" do
+    even_rule = fn n -> if rem(n, 2) == 0, do: "Even", else: nil end
+
+    assert CustomRule.generate_with(4, even_rule) == "Even"
+    assert CustomRule.generate_with(3, even_rule) == "3"
+  end
+
+  test "generate_with/2 はルール関数リストを順に適用する" do
+    rules = [
+      fn n -> if rem(n, 7) == 0, do: "Pop", else: nil end,
+      fn n -> if rem(n, 3) == 0, do: "Fizz", else: nil end
+    ]
+
+    assert CustomRule.generate_with(14, rules) == "Pop"
+    assert CustomRule.generate_with(9, rules) == "Fizz"
+    assert CustomRule.generate_with(2, rules) == "2"
+  end
+
+  test "transform/2 と filter/2 を組み合わせて再利用できる" do
+    values = 1..6 |> Enum.to_list()
+
+    assert values
+           |> Collection.transform(&(&1 * 10))
+           |> Collection.filter(&(&1 > 30)) == [40, 50, 60]
+  end
+end
+```
+
+## 10.8 まとめ
+
+この章では、高階関数、無名関数、`|>` パイプライン演算子を使って処理を小さな関数へ分解し、合成する方法を確認しました。`generate_with/2`、`transform/2`、`filter/2` のように関数を受け取る設計により、仕様変更に強い実装を作れます。