@k2works/claude-code-booster 3.0.0 → 3.1.0

package/lib/assets/docs/article/getting-start-tdd/ruby/02-fake-it-and-triangulation.md

@@ -0,0 +1,238 @@
+# 第 2 章: 仮実装と三角測量
+
+## 2.1 はじめに
+
+前章では、FizzBuzz の仕様を TODO リストに分解し、最初のテストを仮実装で通しました。この章では、**三角測量** によってプログラムを一般化し、さらに FizzBuzz のコアロジックを実装していきます。
+
+**TODO リスト**:
+
+- [ ] 数を文字列にして返す
+  - [x] 1 を渡したら文字列 "1" を返す
+  - [ ] 2 を渡したら文字列 "2" を返す
+- [ ] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [ ] 5 の倍数のときは「Buzz」と返す
+- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 2.2 三角測量
+
+1 を渡したら文字列 "1" を返すようにできました。では、2 を渡したらどうなるでしょうか？
+
+### Red: 2 つ目のテストを書く
+
+```ruby
+def test_2を渡したら文字列2を返す
+  assert_equal '2', @fizzbuzz.generate(2)
+end
+```
+
+テストを実行します。
+
+```bash
+$ bundle exec rake test
+ FAIL["test_2を渡したら文字列2を返す", FizzBuzzTest]
+        Expected: "2"
+          Actual: "1"
+
+2 tests, 2 assertions, 1 failures, 0 errors, 0 skips
+```
+
+テストが失敗しました。文字列 "1" しか返さないプログラムなのですから当然です。
+
+### Green: 一般化する
+
+数値を文字列に変換して返すように修正します。Ruby では `to_s` メソッドでオブジェクトを文字列に変換できます。
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    number.to_s
+  end
+end
+```
+
+テストを実行します。
+
+```bash
+$ bundle exec rake test
+Started with run options --seed 42479
+
+  2/2: [==========] 100% Time: 00:00:00
+
+Finished in 0.00098s
+2 tests, 2 assertions, 0 failures, 0 errors, 0 skips
+```
+
+テストが通りました！2 つ目のテストによって `generate` メソッドの一般化を実現できました。このようなアプローチを **三角測量** と言います。
+
+> 三角測量
+>
+> テストから最も慎重に一般化を引き出すやり方はどのようなものだろうか——2 つ以上の例があるときだけ、一般化を行うようにしよう。
+>
+> — テスト駆動開発
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+  - [x] 1 を渡したら文字列 "1" を返す
+  - [x] 2 を渡したら文字列 "2" を返す
+- [ ] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [ ] 5 の倍数のときは「Buzz」と返す
+- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 2.3 3 の倍数 — Fizz
+
+次は「3 の倍数のときは数の代わりに Fizz と返す」に取り掛かります。
+
+### Red: 3 の倍数のテスト
+
+```ruby
+def test_3を渡したらFizzを返す
+  assert_equal 'Fizz', @fizzbuzz.generate(3)
+end
+```
+
+```bash
+$ bundle exec rake test
+ FAIL["test_3を渡したらFizzを返す", FizzBuzzTest]
+        Expected: "Fizz"
+          Actual: "3"
+```
+
+### Green: 明白な実装
+
+3 の倍数のときは "Fizz" を返すように実装します。Ruby では `%` 演算子で剰余を求め、`.zero?` メソッドでゼロかどうかを判定できます。
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    return 'Fizz' if (number % 3).zero?
+
+    number.to_s
+  end
+end
+```
+
+```bash
+$ bundle exec rake test
+3 tests, 3 assertions, 0 failures, 0 errors, 0 skips
+```
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [ ] 5 の倍数のときは「Buzz」と返す
+- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 2.4 5 の倍数 — Buzz
+
+### Red: 5 の倍数のテスト
+
+```ruby
+def test_5を渡したらBuzzを返す
+  assert_equal 'Buzz', @fizzbuzz.generate(5)
+end
+```
+
+```bash
+$ bundle exec rake test
+ FAIL["test_5を渡したらBuzzを返す", FizzBuzzTest]
+        Expected: "Buzz"
+          Actual: "5"
+```
+
+### Green: Buzz の実装
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    return 'Fizz' if (number % 3).zero?
+    return 'Buzz' if (number % 5).zero?
+
+    number.to_s
+  end
+end
+```
+
+```bash
+$ bundle exec rake test
+4 tests, 4 assertions, 0 failures, 0 errors, 0 skips
+```
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 2.5 15 の倍数 — FizzBuzz
+
+### Red: 15 の倍数のテスト
+
+```ruby
+def test_15を渡したらFizzBuzzを返す
+  assert_equal 'FizzBuzz', @fizzbuzz.generate(15)
+end
+```
+
+```bash
+$ bundle exec rake test
+ FAIL["test_15を渡したらFizzBuzzを返す", FizzBuzzTest]
+        Expected: "FizzBuzz"
+          Actual: "Fizz"
+```
+
+15 は 3 の倍数でもあるため、"Fizz" が返されてしまいました。3 と 5 の両方の倍数の判定を先に行う必要があります。
+
+### Green: FizzBuzz の実装
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    return 'FizzBuzz' if (number % 15).zero?
+    return 'Fizz' if (number % 3).zero?
+    return 'Buzz' if (number % 5).zero?
+
+    number.to_s
+  end
+end
+```
+
+```bash
+$ bundle exec rake test
+5 tests, 5 assertions, 0 failures, 0 errors, 0 skips
+```
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [ ] 1 から 100 までの数
+- [ ] プリントする
+
+## 2.6 まとめ
+
+この章では以下のことを学びました。
+
+- **三角測量** で 2 つ以上の例を使ってプログラムを一般化する手法
+- Ruby の `to_s` メソッドによるオブジェクトの文字列変換
+- Ruby の `%` 演算子と `.zero?` メソッドによる剰余判定
+- `return ... if` 構文によるガード節（早期リターン）
+- Red-Green サイクルを繰り返してコアロジックを段階的に構築する方法
+
+次章では、残りの TODO（リスト生成とプリント）を実装し、リファクタリングで「動作するきれいなコード」を目指します。

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

@@ -0,0 +1,228 @@
+# 第 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 の結果をリストとして返すメソッドをテストします。
+
+```ruby
+def test_1から100までの数の配列を返す
+  result = @fizzbuzz.generate_list
+  assert_equal 100, result.length
+  assert_equal '1', result[0]
+  assert_equal '2', result[1]
+  assert_equal 'Fizz', result[2]
+  assert_equal '4', result[3]
+  assert_equal 'Buzz', result[4]
+  assert_equal 'FizzBuzz', result[14]
+end
+```
+
+```bash
+$ bundle exec rake test
+ERROR["test_1から100までの数の配列を返す", FizzBuzzTest]
+ NoMethodError: undefined method 'generate_list' for FizzBuzz:Class
+```
+
+### Green: 明白な実装
+
+Ruby の `Range` と `map` メソッドを使って、1 から 100 までの数を FizzBuzz に変換したリストを返します。
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    return 'FizzBuzz' if (number % 15).zero?
+    return 'Fizz' if (number % 3).zero?
+    return 'Buzz' if (number % 5).zero?
+
+    number.to_s
+  end
+
+  def self.generate_list
+    (1..100).map { |n| generate(n) }
+  end
+end
+```
+
+```bash
+$ bundle exec rake test
+6 tests, 12 assertions, 0 failures, 0 errors, 0 skips
+```
+
+`(1..100)` は Ruby の `Range` オブジェクトで、`map` メソッドは各要素にブロックを適用して新しい配列を返します。Java の `IntStream.rangeClosed(1, 100).mapToObj(...)` や Python のリスト内包表記 `[generate(n) for n in range(1, 101)]` に相当します。
+
+> 明白な実装
+>
+> シンプルな操作を実現するにはどうすればいいだろうか——そのまま実装しよう。
+>
+> — テスト駆動開発
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [x] 1 から 100 までの数
+- [ ] プリントする
+
+## 3.3 プリント機能
+
+### 学習用テスト
+
+プリント機能は、生成したリストの各要素を標準出力に出力するものです。学習用テストとして、`$stdout` のリダイレクトを試します。
+
+> 学習用テスト
+>
+> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
+>
+> — テスト駆動開発
+
+Ruby では `StringIO` を使って標準出力をキャプチャできます。
+
+```ruby
+require 'stringio'
+
+def test_プリントする
+  out = StringIO.new
+  $stdout = out
+  @fizzbuzz.generate_list.each { |item| puts item }
+  $stdout = STDOUT
+  output = out.string
+  assert_includes output, '1'
+  assert_includes output, 'Fizz'
+  assert_includes output, 'Buzz'
+  assert_includes output, 'FizzBuzz'
+end
+```
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [x] 1 から 100 までの数
+- [x] プリントする
+
+## 3.4 リファクタリング
+
+テスト駆動開発の流れを確認しておきましょう。
+
+> 1. レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを 1 つ書く。
+> 2. グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
+> 3. リファクタリング：テストを通すために発生した重複をすべて除去する。
+>
+> レッド・グリーン・リファクタリング。それが TDD のマントラだ。
+>
+> — テスト駆動開発
+
+### テストコードのリファクタリング
+
+テストコードに重複はないでしょうか？`setup` メソッドで `FizzBuzz` クラスの参照を共有しているので、すでに一定のリファクタリングができています。
+
+現在のテストコード全体を確認します。
+
+```ruby
+# test/fizz_buzz_test.rb
+require_relative 'test_helper'
+require_relative '../lib/fizz_buzz'
+
+class FizzBuzzTest < Minitest::Test
+  def setup
+    @fizzbuzz = FizzBuzz
+  end
+
+  def test_1を渡したら文字列1を返す
+    assert_equal '1', @fizzbuzz.generate(1)
+  end
+
+  def test_2を渡したら文字列2を返す
+    assert_equal '2', @fizzbuzz.generate(2)
+  end
+
+  def test_3を渡したらFizzを返す
+    assert_equal 'Fizz', @fizzbuzz.generate(3)
+  end
+
+  def test_5を渡したらBuzzを返す
+    assert_equal 'Buzz', @fizzbuzz.generate(5)
+  end
+
+  def test_15を渡したらFizzBuzzを返す
+    assert_equal 'FizzBuzz', @fizzbuzz.generate(15)
+  end
+
+  def test_1から100までの数の配列を返す
+    result = @fizzbuzz.generate_list
+    assert_equal 100, result.length
+    assert_equal '1', result[0]
+    assert_equal '2', result[1]
+    assert_equal 'Fizz', result[2]
+    assert_equal '4', result[3]
+    assert_equal 'Buzz', result[4]
+    assert_equal 'FizzBuzz', result[14]
+  end
+end
+```
+
+各テストメソッドは独立しており、1 テスト 1 アサーション（リスト生成テストを除く）の原則に従っています。テストの本質は「こういう状況と入力から、こういう振る舞いと出力を期待する」のレベルまで要約できます。
+
+### プロダクションコードの確認
+
+```ruby
+# lib/fizz_buzz.rb
+class FizzBuzz
+  def self.generate(number)
+    return 'FizzBuzz' if (number % 15).zero?
+    return 'Fizz' if (number % 3).zero?
+    return 'Buzz' if (number % 5).zero?
+
+    number.to_s
+  end
+
+  def self.generate_list
+    (1..100).map { |n| generate(n) }
+  end
+end
+```
+
+プロダクションコードは十分にシンプルで、リファクタリングの必要はありません。Ruby のガード節スタイル（`return ... if`）は、Java の `if-else if-else` チェーンよりも読みやすく簡潔です。
+
+## 3.5 他言語との比較
+
+| 概念 | Java | Python | TypeScript | Ruby |
+|------|------|--------|-----------|------|
+| テストフレームワーク | JUnit 5 | pytest | Vitest | Minitest |
+| テスト実行 | `./gradlew test` | `pytest` | `npx vitest` | `bundle exec rake test` |
+| 文字列変換 | `String.valueOf(n)` | `str(n)` | `n.toString()` | `n.to_s` |
+| 剰余判定 | `n % 3 == 0` | `n % 3 == 0` | `n % 3 === 0` | `(n % 3).zero?` |
+| リスト生成 | `IntStream.rangeClosed` | `[f(n) for n in range]` | `Array.from({length})` | `(1..100).map { }` |
+| ガード節 | `if (...) return` | `if ...: return` | `if (...) return` | `return ... if` |
+
+## 3.6 まとめ
+
+この章では以下のことを学びました。
+
+- **明白な実装** でシンプルな操作をそのまま実装する手法
+- Ruby の `Range` オブジェクトと `map` メソッドによるリスト生成
+- `StringIO` を使った標準出力のキャプチャ（学習用テスト）
+- **リファクタリング** でテストを通すために発生した重複を除去する考え方
+- Red-Green-Refactor サイクルの完了
+
+第 1 部の 3 章を通じて、TDD の基本サイクル（仮実装 → 三角測量 → 明白な実装 → リファクタリング）を一通り体験しました。次の第 2 部では、開発環境の自動化（バージョン管理、パッケージ管理、CI/CD）に進みます。

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

@@ -0,0 +1,112 @@
+# 第 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 の倍数の判定ロジックを修正'
+
+# リファクタリング
+$ git commit -m 'refactor: generate メソッドの条件分岐を整理'
+
+# テストの追加
+$ git commit -m 'test: FizzBuzz の境界値テストを追加'
+
+# ビルド設定の変更
+$ git commit -m 'chore: Gemfile に Guard 関連 gem を追加'
+```
+
+## 4.4 TDD とコミットのタイミング
+
+TDD の Red-Green-Refactor サイクルにおいて、コミットする適切なタイミングは以下の通りです。
+
+```
+Red（テスト作成）→ Green（テスト成功）→ コミット → Refactor（リファクタリング）→ コミット
+```
+
+1. **Green の後** — テストが通った時点でコミット（`feat:` や `fix:`）
+2. **Refactor の後** — リファクタリングが完了しテストがパスした時点でコミット（`refactor:`）
+
+### 実際のコミット例
+
+FizzBuzz の開発過程では、以下のようなコミット履歴になります。
+
+```bash
+$ git log --oneline
+
+abc1234 refactor: generate メソッドの条件順序を最適化
+def5678 feat: 3 と 5 の倍数で FizzBuzz を返す機能を追加
+ghi9012 feat: 5 の倍数で Buzz を返す機能を追加
+jkl3456 feat: 3 の倍数で Fizz を返す機能を追加
+mno7890 feat: 数を文字列に変換する generate メソッドを実装
+pqr1234 test: FizzBuzz の最初のテストを作成
+stu5678 chore: Ruby プロジェクトを初期化（Minitest + Bundler）
+```
+
+各コミットが小さく、明確な目的を持っていることがわかります。
+
+## 4.5 まとめ
+
+この章では、以下の内容を学びました。
+
+1. **Conventional Commits** — コミットメッセージの統一フォーマット
+2. **コミットのタイプ** — feat、fix、refactor、test、chore などの使い分け
+3. **TDD とコミットのタイミング** — Green 後と Refactor 後にコミット
+
+次の章では、パッケージ管理ツールと静的コード解析を導入し、コードの品質を自動でチェックできるようにします。