@k2works/claude-code-booster 3.4.1 → 3.6.0

package/lib/assets/docs/article/getting-start-tdd/java/03-obvious-implementation-and-refactoring.md

@@ -1,185 +1,185 @@
-# 第 3 章: 明白な実装とリファクタリング
-
-## 3.1 はじめに
-
-前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。この章では、残りの TODO（リスト生成とプリント）を実装し、学習用テストを活用しながら「動作するきれいなコード」を目指してリファクタリングします。
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 3.2 1 から 100 までのリスト生成
-
-### Red: リスト生成のテスト
-
-1 から 100 までの FizzBuzz の結果をリストとして返すメソッドをテストします。
-
-```java
-@Test
-void test_1から100までのFizzBuzzを生成する() {
-    List<String> result = fizzbuzz.generateList(100);
-
-    assertEquals(100, result.size());
-    assertEquals("1", result.get(0));
-    assertEquals("2", result.get(1));
-    assertEquals("Fizz", result.get(2));
-    assertEquals("4", result.get(3));
-    assertEquals("Buzz", result.get(4));
-    assertEquals("Fizz", result.get(5));
-    assertEquals("FizzBuzz", result.get(14));
-    assertEquals("Buzz", result.get(99));
-}
-```
-
-```
-FizzBuzzTest > test_1から100までのFizzBuzzを生成する() FAILED
-    java.lang.NoSuchMethodError: tdd.fizzbuzz.FizzBuzz.generateList(int)
-```
-
-### Green: 明白な実装
-
-```java
-package tdd.fizzbuzz;
-
-import java.util.ArrayList;
-import java.util.List;
-
-public class FizzBuzz {
-
-    public String generate(int number) {
-        if (number % 3 == 0 && number % 5 == 0) {
-            return "FizzBuzz";
-        } else if (number % 3 == 0) {
-            return "Fizz";
-        } else if (number % 5 == 0) {
-            return "Buzz";
-        }
-        return String.valueOf(number);
-    }
-
-    public List<String> generateList(int count) {
-        List<String> result = new ArrayList<>();
-        for (int i = 1; i <= count; i++) {
-            result.add(generate(i));
-        }
-        return result;
-    }
-}
-```
-
-```
-FizzBuzzTest > test_1から100までのFizzBuzzを生成する() PASSED
-
-BUILD SUCCESSFUL
-```
-
-## 3.3 プリント機能
-
-### 学習用テスト
-
-プリント機能のテストには、標準出力のキャプチャが必要です。学習用テストとして、`System.out` のリダイレクトを試します。
-
-> 学習用テスト
->
-> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
->
-> — テスト駆動開発
-
-```java
-@Test
-void test_プリントする() {
-    fizzbuzz.printFizzBuzz(15);
-    // コンソール出力を確認（学習用テスト）
-    // 実際のアプリケーションでは Main クラスから呼び出す
-}
-```
-
-### 実装
-
-```java
-public void printFizzBuzz(int count) {
-    List<String> result = generateList(count);
-    for (String s : result) {
-        System.out.println(s);
-    }
-}
-```
-
-### Main クラスの作成
-
-実行用の Main クラスを作成します。
-
-```java
-package tdd.fizzbuzz;
-
-public class Main {
-    public static void main(String[] args) {
-        FizzBuzz fizzBuzz = new FizzBuzz();
-        fizzBuzz.printFizzBuzz(100);
-    }
-}
-```
-
-## 3.4 動作するきれいなコード
-
-ここまでの実装で、すべての TODO が完了しました。
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [x] 1 から 100 までの数
-- [x] プリントする
-
-TDD では「動作するきれいなコード（Clean code that works）」を目指します。これはソフトウェア開発の三種の神器と組み合わせて実現します。
-
-> ソフトウェア開発の三種の神器
->
-> - バージョン管理
-> - テスティング
-> - 自動化
->
-> — 和田卓人
-
-現在のコードは動作していますが、テスト駆動開発のプロセスを振り返ってみましょう。
-
-### TDD サイクルの振り返り
-
-1. **仮実装** — `return "1"` でテストを通す
-2. **三角測量** — 2 つ目のテストで `String.valueOf(number)` に一般化
-3. **明白な実装** — 3 の倍数、5 の倍数、15 の倍数の判定を直接実装
-4. **追加実装** — リスト生成、プリント機能を追加
-
-各ステップでテストが先にあり、テストが通ることを確認してから次のステップに進みました。これが TDD の基本サイクルです。
-
-## 3.5 まとめ
-
-第 1 部（章 1〜3）を通じて、TDD の基本サイクルを体験しました。
-
-### 学んだ TDD テクニック
-
-| テクニック | 説明 | 使用場面 |
-|-----------|------|---------|
-| テストファースト | テスト対象のコードを書く前にテストを書く | 常に |
-| アサートファースト | アサーションを最初に書く | テスト作成時 |
-| 仮実装 | ベタ書きの値を返す | 最初の実装 |
-| 三角測量 | 2 つ以上の例から一般化を導く | 実装の方向性が不明確なとき |
-| 明白な実装 | ロジックが明確な場合は直接実装 | ロジックが自明なとき |
-| 学習用テスト | 外部ソフトウェアの使い方を学ぶためのテスト | 新しい API を使うとき |
-
-### Red-Green-Refactor
-
-```
-Red（テスト失敗）→ Green（テスト成功）→ Refactor（リファクタリング）
-```
-
-このサイクルを小さく素早く繰り返すことで、品質を維持しながら着実に機能を追加できます。
-
-次の第 2 部では、開発環境の整備（バージョン管理、パッケージ管理、CI/CD）について解説します。
+# 第 3 章: 明白な実装とリファクタリング
+
+## 3.1 はじめに
+
+前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。この章では、残りの TODO（リスト生成とプリント）を実装し、学習用テストを活用しながら「動作するきれいなコード」を目指してリファクタリングします。
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 3.2 1 から 100 までのリスト生成
+
+### Red: リスト生成のテスト
+
+1 から 100 までの FizzBuzz の結果をリストとして返すメソッドをテストします。
+
+```java
+@Test
+void test_1から100までのFizzBuzzを生成する() {
+    List<String> result = fizzbuzz.generateList(100);
+
+    assertEquals(100, result.size());
+    assertEquals("1", result.get(0));
+    assertEquals("2", result.get(1));
+    assertEquals("Fizz", result.get(2));
+    assertEquals("4", result.get(3));
+    assertEquals("Buzz", result.get(4));
+    assertEquals("Fizz", result.get(5));
+    assertEquals("FizzBuzz", result.get(14));
+    assertEquals("Buzz", result.get(99));
+}
+```
+
+```
+FizzBuzzTest > test_1から100までのFizzBuzzを生成する() FAILED
+    java.lang.NoSuchMethodError: tdd.fizzbuzz.FizzBuzz.generateList(int)
+```
+
+### Green: 明白な実装
+
+```java
+package tdd.fizzbuzz;
+
+import java.util.ArrayList;
+import java.util.List;
+
+public class FizzBuzz {
+
+    public String generate(int number) {
+        if (number % 3 == 0 && number % 5 == 0) {
+            return "FizzBuzz";
+        } else if (number % 3 == 0) {
+            return "Fizz";
+        } else if (number % 5 == 0) {
+            return "Buzz";
+        }
+        return String.valueOf(number);
+    }
+
+    public List<String> generateList(int count) {
+        List<String> result = new ArrayList<>();
+        for (int i = 1; i <= count; i++) {
+            result.add(generate(i));
+        }
+        return result;
+    }
+}
+```
+
+```
+FizzBuzzTest > test_1から100までのFizzBuzzを生成する() PASSED
+
+BUILD SUCCESSFUL
+```
+
+## 3.3 プリント機能
+
+### 学習用テスト
+
+プリント機能のテストには、標準出力のキャプチャが必要です。学習用テストとして、`System.out` のリダイレクトを試します。
+
+> 学習用テスト
+>
+> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
+>
+> — テスト駆動開発
+
+```java
+@Test
+void test_プリントする() {
+    fizzbuzz.printFizzBuzz(15);
+    // コンソール出力を確認（学習用テスト）
+    // 実際のアプリケーションでは Main クラスから呼び出す
+}
+```
+
+### 実装
+
+```java
+public void printFizzBuzz(int count) {
+    List<String> result = generateList(count);
+    for (String s : result) {
+        System.out.println(s);
+    }
+}
+```
+
+### Main クラスの作成
+
+実行用の Main クラスを作成します。
+
+```java
+package tdd.fizzbuzz;
+
+public class Main {
+    public static void main(String[] args) {
+        FizzBuzz fizzBuzz = new FizzBuzz();
+        fizzBuzz.printFizzBuzz(100);
+    }
+}
+```
+
+## 3.4 動作するきれいなコード
+
+ここまでの実装で、すべての TODO が完了しました。
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [x] 1 から 100 までの数
+- [x] プリントする
+
+TDD では「動作するきれいなコード（Clean code that works）」を目指します。これはソフトウェア開発の三種の神器と組み合わせて実現します。
+
+> ソフトウェア開発の三種の神器
+>
+> - バージョン管理
+> - テスティング
+> - 自動化
+>
+> — 和田卓人
+
+現在のコードは動作していますが、テスト駆動開発のプロセスを振り返ってみましょう。
+
+### TDD サイクルの振り返り
+
+1. **仮実装** — `return "1"` でテストを通す
+2. **三角測量** — 2 つ目のテストで `String.valueOf(number)` に一般化
+3. **明白な実装** — 3 の倍数、5 の倍数、15 の倍数の判定を直接実装
+4. **追加実装** — リスト生成、プリント機能を追加
+
+各ステップでテストが先にあり、テストが通ることを確認してから次のステップに進みました。これが TDD の基本サイクルです。
+
+## 3.5 まとめ
+
+第 1 部（章 1〜3）を通じて、TDD の基本サイクルを体験しました。
+
+### 学んだ TDD テクニック
+
+| テクニック | 説明 | 使用場面 |
+|-----------|------|---------|
+| テストファースト | テスト対象のコードを書く前にテストを書く | 常に |
+| アサートファースト | アサーションを最初に書く | テスト作成時 |
+| 仮実装 | ベタ書きの値を返す | 最初の実装 |
+| 三角測量 | 2 つ以上の例から一般化を導く | 実装の方向性が不明確なとき |
+| 明白な実装 | ロジックが明確な場合は直接実装 | ロジックが自明なとき |
+| 学習用テスト | 外部ソフトウェアの使い方を学ぶためのテスト | 新しい API を使うとき |
+
+### Red-Green-Refactor
+
+```
+Red（テスト失敗）→ Green（テスト成功）→ Refactor（リファクタリング）
+```
+
+このサイクルを小さく素早く繰り返すことで、品質を維持しながら着実に機能を追加できます。
+
+次の第 2 部では、開発環境の整備（バージョン管理、パッケージ管理、CI/CD）について解説します。

package/lib/assets/docs/article/getting-start-tdd/java/04-version-control-and-conventional-commits.md

@@ -1,115 +1,115 @@
-# 第 4 章: バージョン管理と Conventional Commits
-
-## 4.1 はじめに
-
-前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。この章からは「動作するきれいなコード」を書き続けるために必要な **ソフトウェア開発の三種の神器** を整備していきます。
-
-> 今日のソフトウェア開発の世界において絶対になければならない 3 つの技術的な柱があります。三本柱と言ったり、三種の神器と言ったりしていますが、それらは
->
-> - バージョン管理
-> - テスティング
-> - 自動化
->
-> の 3 つです。
->
-> — 和田卓人
-
-**バージョン管理** と **テスティング** に関しては第 1 部で触れました。本章ではバージョン管理をさらに深掘りし、**コミットメッセージの規約** について解説します。
-
-## 4.2 コミットメッセージの重要性
-
-これまでの作業では、区切りごとにリポジトリにコミットしてきました。しかし、コミットメッセージの書き方に一貫性がないと、後からプロジェクトの履歴を追うのが難しくなります。
-
-チーム開発では特に、誰がいつ何のためにコードを変更したのかを明確にすることが重要です。そこで役立つのが **Conventional Commits** です。
-
-## 4.3 Conventional Commits
-
-本プロジェクトでは [Angular ルール](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) に基づいた **Conventional Commits** の書式を採用します。
-
-### コミットメッセージのフォーマット
-
-```
-<タイプ>(<スコープ>): <タイトル>
-<空行>
-<ボディ>
-<空行>
-<フッタ>
-```
-
-- **ヘッダ** は必須です
-- **スコープ** は任意です
-- タイトルは **50 文字以内** にしてください（GitHub 上で読みやすくなります）
-
-### コミットのタイプ
-
-| タイプ | 説明 | 使用場面 |
-|--------|------|---------|
-| `feat` | A new feature（新しい機能） | 新機能の追加 |
-| `fix` | A bug fix（バグ修正） | バグの修正 |
-| `docs` | Documentation only changes（ドキュメント変更のみ） | README やコメントの更新 |
-| `style` | Changes that do not affect the meaning of the code（コードに影響を与えない変更） | フォーマット、セミコロンの追加など |
-| `refactor` | A code change that neither fixes a bug nor adds a feature（リファクタリング） | コード構造の改善 |
-| `perf` | A code change that improves performance（パフォーマンス改善） | 処理速度の向上 |
-| `test` | Adding missing or correcting existing tests（テストの追加・修正） | テストコードの変更 |
-| `chore` | Changes to the build process or auxiliary tools（ビルドプロセスや補助ツールの変更） | 設定ファイルの更新 |
-
-### コミットメッセージの例
-
-```bash
-# 新機能の追加
-$ git commit -m 'feat: FizzBuzz のリスト生成機能を追加'
-
-# バグ修正
-$ git commit -m 'fix: 15 の倍数で FizzBuzz が返らない問題を修正'
-
-# リファクタリング
-$ git commit -m 'refactor: メソッドの抽出'
-
-# テストの追加
-$ git commit -m 'test: 3 の倍数のテストケースを追加'
-
-# ビルド設定の変更
-$ git commit -m 'chore: 静的コード解析セットアップ'
-
-# ドキュメントの更新
-$ git commit -m 'docs: README にプロジェクト概要を追加'
-```
-
-### スコープ付きのコミットメッセージ
-
-スコープを使うと、変更の影響範囲をより明確にできます。
-
-```bash
-$ git commit -m 'feat(fizzbuzz): generate メソッドに Fizz 判定を追加'
-$ git commit -m 'chore(gradle): JaCoCo プラグインを追加'
-$ git commit -m 'test(fizzbuzz): パラメータ化テストに変換'
-```
-
-## 4.4 TDD とコミットのタイミング
-
-TDD サイクルでは、以下のタイミングでコミットすることを推奨します。
-
-```
-Red（テスト失敗）→ Green（テスト成功）→ Refactor → **Commit**
-```
-
-具体的には：
-
-1. **Green の後** — テストが通ったらコミット（`feat` または `fix`）
-2. **Refactor の後** — リファクタリングが完了したらコミット（`refactor`）
-3. **設定変更の後** — ビルド設定やツール設定を変更したらコミット（`chore`）
-
-小さな変更を頻繁にコミットすることで、問題が発生した際に原因を特定しやすくなります。
-
-## 4.5 まとめ
-
-この章では、バージョン管理の実践として Conventional Commits を学びました。
-
-| 項目 | 内容 |
-|------|------|
-| コミットメッセージ規約 | Angular ルールに基づく Conventional Commits |
-| フォーマット | `<タイプ>(<スコープ>): <タイトル>` |
-| タイプ | feat, fix, docs, style, refactor, perf, test, chore |
-| コミットタイミング | TDD サイクルの Green/Refactor 完了後 |
-
-次の章では、パッケージ管理と静的コード解析ツールを導入し、コードの品質を自動でチェックできるようにします。
+# 第 4 章: バージョン管理と Conventional Commits
+
+## 4.1 はじめに
+
+前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。この章からは「動作するきれいなコード」を書き続けるために必要な **ソフトウェア開発の三種の神器** を整備していきます。
+
+> 今日のソフトウェア開発の世界において絶対になければならない 3 つの技術的な柱があります。三本柱と言ったり、三種の神器と言ったりしていますが、それらは
+>
+> - バージョン管理
+> - テスティング
+> - 自動化
+>
+> の 3 つです。
+>
+> — 和田卓人
+
+**バージョン管理** と **テスティング** に関しては第 1 部で触れました。本章ではバージョン管理をさらに深掘りし、**コミットメッセージの規約** について解説します。
+
+## 4.2 コミットメッセージの重要性
+
+これまでの作業では、区切りごとにリポジトリにコミットしてきました。しかし、コミットメッセージの書き方に一貫性がないと、後からプロジェクトの履歴を追うのが難しくなります。
+
+チーム開発では特に、誰がいつ何のためにコードを変更したのかを明確にすることが重要です。そこで役立つのが **Conventional Commits** です。
+
+## 4.3 Conventional Commits
+
+本プロジェクトでは [Angular ルール](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) に基づいた **Conventional Commits** の書式を採用します。
+
+### コミットメッセージのフォーマット
+
+```
+<タイプ>(<スコープ>): <タイトル>
+<空行>
+<ボディ>
+<空行>
+<フッタ>
+```
+
+- **ヘッダ** は必須です
+- **スコープ** は任意です
+- タイトルは **50 文字以内** にしてください（GitHub 上で読みやすくなります）
+
+### コミットのタイプ
+
+| タイプ | 説明 | 使用場面 |
+|--------|------|---------|
+| `feat` | A new feature（新しい機能） | 新機能の追加 |
+| `fix` | A bug fix（バグ修正） | バグの修正 |
+| `docs` | Documentation only changes（ドキュメント変更のみ） | README やコメントの更新 |
+| `style` | Changes that do not affect the meaning of the code（コードに影響を与えない変更） | フォーマット、セミコロンの追加など |
+| `refactor` | A code change that neither fixes a bug nor adds a feature（リファクタリング） | コード構造の改善 |
+| `perf` | A code change that improves performance（パフォーマンス改善） | 処理速度の向上 |
+| `test` | Adding missing or correcting existing tests（テストの追加・修正） | テストコードの変更 |
+| `chore` | Changes to the build process or auxiliary tools（ビルドプロセスや補助ツールの変更） | 設定ファイルの更新 |
+
+### コミットメッセージの例
+
+```bash
+# 新機能の追加
+$ git commit -m 'feat: FizzBuzz のリスト生成機能を追加'
+
+# バグ修正
+$ git commit -m 'fix: 15 の倍数で FizzBuzz が返らない問題を修正'
+
+# リファクタリング
+$ git commit -m 'refactor: メソッドの抽出'
+
+# テストの追加
+$ git commit -m 'test: 3 の倍数のテストケースを追加'
+
+# ビルド設定の変更
+$ git commit -m 'chore: 静的コード解析セットアップ'
+
+# ドキュメントの更新
+$ git commit -m 'docs: README にプロジェクト概要を追加'
+```
+
+### スコープ付きのコミットメッセージ
+
+スコープを使うと、変更の影響範囲をより明確にできます。
+
+```bash
+$ git commit -m 'feat(fizzbuzz): generate メソッドに Fizz 判定を追加'
+$ git commit -m 'chore(gradle): JaCoCo プラグインを追加'
+$ git commit -m 'test(fizzbuzz): パラメータ化テストに変換'
+```
+
+## 4.4 TDD とコミットのタイミング
+
+TDD サイクルでは、以下のタイミングでコミットすることを推奨します。
+
+```
+Red（テスト失敗）→ Green（テスト成功）→ Refactor → **Commit**
+```
+
+具体的には：
+
+1. **Green の後** — テストが通ったらコミット（`feat` または `fix`）
+2. **Refactor の後** — リファクタリングが完了したらコミット（`refactor`）
+3. **設定変更の後** — ビルド設定やツール設定を変更したらコミット（`chore`）
+
+小さな変更を頻繁にコミットすることで、問題が発生した際に原因を特定しやすくなります。
+
+## 4.5 まとめ
+
+この章では、バージョン管理の実践として Conventional Commits を学びました。
+
+| 項目 | 内容 |
+|------|------|
+| コミットメッセージ規約 | Angular ルールに基づく Conventional Commits |
+| フォーマット | `<タイプ>(<スコープ>): <タイトル>` |
+| タイプ | feat, fix, docs, style, refactor, perf, test, chore |
+| コミットタイミング | TDD サイクルの Green/Refactor 完了後 |
+
+次の章では、パッケージ管理と静的コード解析ツールを導入し、コードの品質を自動でチェックできるようにします。