@k2works/claude-code-booster 3.0.0 → 3.1.0

package/lib/assets/docs/article/getting-start-tdd/csharp/chapter03.md

@@ -0,0 +1,202 @@
+# 第 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 の結果を `List<string>` として返すメソッドをテストします。
+
+```csharp
+[Fact]
+public void 一から百までのリストを生成する()
+{
+    var list = FizzBuzzRunner.GenerateList(100);
+    Assert.Equal(100, list.Count);
+    Assert.Equal("1", list[0]);
+    Assert.Equal("Fizz", list[2]);
+    Assert.Equal("Buzz", list[4]);
+    Assert.Equal("FizzBuzz", list[14]);
+}
+```
+
+```bash
+$ dotnet test
+# コンパイルエラー: GenerateList が見つからない
+```
+
+### Green: 明白な実装
+
+C# の `Enumerable.Range` と LINQ の `Select` を使って、指定個数の FizzBuzz リストを生成します。
+
+```csharp
+public static List<string> GenerateList(int count)
+{
+    return Enumerable.Range(1, count)
+        .Select(i => Generate(i))
+        .ToList();
+}
+```
+
+```bash
+$ dotnet test
+成功!   -失敗:     0、合格:     6、スキップ:     0、合計:     6
+```
+
+`Enumerable.Range(1, count)` は 1 から count 個の連続した整数を生成します。`.Select(i => Generate(i))` で各要素に `Generate` メソッドを適用し、`.ToList()` で `List<string>` に変換します。Rust の `(1..=end).map(f).collect()` に相当する C# の書き方です。
+
+> 明白な実装
+>
+> シンプルな操作を実現するにはどうすればいいだろうか——そのまま実装しよう。
+>
+> — テスト駆動開発
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [x] 1 から 100 までの数
+- [ ] プリントする
+
+## 3.3 プリント機能
+
+### 学習用テスト
+
+プリント機能は、生成したリストの各要素を出力するものです。学習用テストとして、C# の `StringWriter` を使った出力のキャプチャ方法を確認します。
+
+> 学習用テスト
+>
+> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
+>
+> — テスト駆動開発
+
+C# では `System.IO.StringWriter` を使って `Console.Out` の出力をキャプチャできます。
+
+```csharp
+[Fact]
+public void 学習用テスト_StringWriterで出力をキャプチャできる()
+{
+    var writer = new StringWriter();
+    Console.SetOut(writer);
+    Console.WriteLine("hello");
+    Assert.Contains("hello", writer.ToString());
+    Console.SetOut(new StreamWriter(Console.OpenStandardOutput()) { AutoFlush = true });
+}
+```
+
+### Print メソッドの実装
+
+`TextWriter` を引数に取ることで、テスト時には `StringWriter` に、本番では標準出力に出力できます。
+
+```csharp
+public static void PrintFizzBuzz(TextWriter writer)
+{
+    foreach (var s in GenerateList(100))
+    {
+        writer.WriteLine(s);
+    }
+}
+```
+
+テストを書きます。
+
+```csharp
+[Fact]
+public void FizzBuzzの結果を出力する()
+{
+    var writer = new StringWriter();
+    FizzBuzzRunner.PrintFizzBuzz(writer);
+    var output = writer.ToString();
+    Assert.Contains("1", output);
+    Assert.Contains("Fizz", output);
+    Assert.Contains("Buzz", output);
+    Assert.Contains("FizzBuzz", output);
+}
+```
+
+**TODO リスト**:
+
+- [x] 数を文字列にして返す
+- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
+- [x] 5 の倍数のときは「Buzz」と返す
+- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
+- [x] 1 から 100 までの数
+- [x] プリントする
+
+## 3.4 リファクタリング
+
+テスト駆動開発の流れを確認しておきましょう。
+
+> 1. レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを 1 つ書く。
+> 2. グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
+> 3. リファクタリング：テストを通すために発生した重複をすべて除去する。
+>
+> レッド・グリーン・リファクタリング。それが TDD のマントラだ。
+>
+> — テスト駆動開発
+
+### プロダクトコードのリファクタリング
+
+条件判定をメソッドに抽出して、意図を明確にします。
+
+```csharp
+public static class FizzBuzzRunner
+{
+    private const int FizzNumber = 3;
+    private const int BuzzNumber = 5;
+
+    public static string Generate(int number)
+    {
+        if (IsFizzBuzz(number)) return "FizzBuzz";
+        if (IsFizz(number)) return "Fizz";
+        if (IsBuzz(number)) return "Buzz";
+        return number.ToString();
+    }
+
+    private static bool IsFizz(int number) => number % FizzNumber == 0;
+    private static bool IsBuzz(int number) => number % BuzzNumber == 0;
+    private static bool IsFizzBuzz(int number) => IsFizz(number) && IsBuzz(number);
+
+    // ...GenerateList, PrintFizzBuzz は同じ
+}
+```
+
+マジックナンバー（3, 5）を定数に抽出し、条件判定を `IsFizz`, `IsBuzz`, `IsFizzBuzz` メソッドに分離しました。C# の `=>` 式本体メンバーにより、単純なメソッドを簡潔に書けます。
+
+## 3.5 他言語との比較
+
+| 概念 | Java | Python | TypeScript | Rust | C# |
+|------|------|--------|-----------|------|------|
+| テストフレームワーク | JUnit 5 | pytest | Vitest | cargo test（標準） | xUnit.net |
+| テスト実行 | `./gradlew test` | `pytest` | `npx vitest` | `cargo test` | `dotnet test` |
+| 文字列変換 | `String.valueOf(n)` | `str(n)` | `n.toString()` | `n.to_string()` | `n.ToString()` |
+| 剰余判定 | `n % 3 == 0` | `n % 3 == 0` | `n % 3 === 0` | `n % 3 == 0` | `n % 3 == 0` |
+| リスト生成 | `IntStream.rangeClosed` | `[f(n) for n in range]` | `Array.from({length})` | `(1..=100).map(f).collect()` | `Enumerable.Range().Select()` |
+| 出力テスト | `System.setOut` | `capsys` fixture | `vi.spyOn` | `Vec<u8>` + `Write` | `StringWriter` |
+
+## 3.6 まとめ
+
+この章では以下のことを学びました。
+
+- **明白な実装** でシンプルな操作をそのまま実装する手法
+- C# の `Enumerable.Range` と `Select` によるリスト生成
+- `TextWriter` を活用したテスタブルな出力設計
+- `StringWriter` を使った出力のキャプチャ（学習用テスト）
+- **リファクタリング** でメソッドの抽出とマジックナンバーの除去を行う考え方
+- Red-Green-Refactor サイクルの完了
+
+第 1 部の 3 章を通じて、TDD の基本サイクル（仮実装 → 三角測量 → 明白な実装 → リファクタリング）を一通り体験しました。次の第 2 部では、開発環境の自動化（バージョン管理、パッケージ管理、CI/CD）に進みます。

package/lib/assets/docs/article/getting-start-tdd/csharp/chapter04.md

@@ -0,0 +1,92 @@
+# 第 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** の書式を採用します。
+
+### コミットメッセージのフォーマット
+
+```
+<タイプ>(<スコープ>): <タイトル>
+<空行>
+<ボディ>
+<空行>
+<フッタ>
+```
+
+### タイプの種類
+
+| タイプ | 説明 | 例 |
+|--------|------|-----|
+| `feat` | 新機能の追加 | `feat: FizzBuzz のコアロジックを実装` |
+| `fix` | バグの修正 | `fix: 15 の倍数の判定順序を修正` |
+| `refactor` | リファクタリング | `refactor: 条件判定をメソッドに抽出` |
+| `test` | テストの追加・修正 | `test: 三角測量のテストケースを追加` |
+| `docs` | ドキュメントの変更 | `docs: README にセットアップ手順を追加` |
+| `chore` | ビルド・ツールの変更 | `chore: NuGet パッケージを更新` |
+| `style` | コードスタイルの変更 | `style: dotnet format で自動フォーマット` |
+
+### C# プロジェクトでの例
+
+```bash
+# テスト追加
+$ git commit -m 'test: 数を文字列にして返す'
+
+# 機能実装
+$ git commit -m 'feat: Generate メソッドで FizzBuzz 判定を実装'
+
+# リファクタリング
+$ git commit -m 'refactor: 条件判定をメソッドに抽出'
+```
+
+## 4.4 Git フロー
+
+### ブランチ戦略
+
+| ブランチ | 用途 |
+|---------|------|
+| `main` | リリース可能な安定版 |
+| `develop` | 開発中の最新コード |
+| `feature/*` | 機能開発用ブランチ |
+
+### 作業の流れ
+
+1. `develop` ブランチから作業を開始
+2. TDD サイクル（Red → Green → Refactor）を実行
+3. Conventional Commits の書式でコミット
+4. テストが通ることを確認してプッシュ
+
+## 4.5 まとめ
+
+この章では以下を学びました。
+
+| 概念 | 説明 |
+|------|------|
+| Conventional Commits | コミットメッセージの標準的な書式 |
+| タイプ | feat, fix, refactor, test, docs, chore, style |
+| スコープ | 変更の影響範囲（任意） |
+| Git フロー | main / develop / feature ブランチ戦略 |
+
+次章では、NuGet によるパッケージ管理と dotnet format による静的解析を導入します。

package/lib/assets/docs/article/getting-start-tdd/csharp/chapter05.md

@@ -0,0 +1,256 @@
+# 第 5 章: パッケージ管理と静的解析
+
+## 5.1 はじめに
+
+前章では Conventional Commits によるコミットメッセージの規約を学びました。この章では、**パッケージ管理** と **静的コード解析** を導入し、コードの品質を自動でチェックできるようにします。
+
+## 5.2 NuGet によるパッケージ管理
+
+### NuGet とは
+
+> NuGet は .NET のパッケージマネージャです。開発者が作成・共有したライブラリやツールを「パッケージ」として配布・利用することができます。
+
+Java の Gradle、Node の npm、Python の pip、Ruby の Bundler、Rust の Cargo に相当するのが NuGet です。
+
+### .csproj ファイルの構成
+
+本プロジェクトの `.csproj` ファイルは以下のようになっています。
+
+```xml
+<Project Sdk="Microsoft.NET.Sdk">
+  <PropertyGroup>
+    <TargetFramework>net8.0</TargetFramework>
+    <ImplicitUsings>enable</ImplicitUsings>
+    <Nullable>enable</Nullable>
+  </PropertyGroup>
+</Project>
+```
+
+テストプロジェクトの `.csproj` にはテスト関連のパッケージが含まれます。
+
+```xml
+<ItemGroup>
+  <PackageReference Include="coverlet.collector" Version="6.0.0" />
+  <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
+  <PackageReference Include="xunit" Version="2.5.3" />
+  <PackageReference Include="xunit.runner.visualstudio" Version="2.5.3" />
+</ItemGroup>
+```
+
+### 主要なコマンド
+
+| コマンド | 説明 |
+|---------|------|
+| `dotnet new <テンプレート>` | 新しいプロジェクトを作成 |
+| `dotnet build` | プロジェクトをビルド |
+| `dotnet test` | テストを実行 |
+| `dotnet run` | アプリケーションを実行 |
+| `dotnet add package <名前>` | NuGet パッケージを追加 |
+| `dotnet restore` | 依存パッケージを復元 |
+
+### NuGet の特徴
+
+- **`packages.lock.json` による再現性** — パッケージバージョンを固定し、チーム全員が同じ環境で開発できる
+- **ソリューション構成** — 複数プロジェクトを 1 つのソリューションで管理
+- **`bin/` / `obj/` ディレクトリ** — Rust の `target/`、Node の `node_modules/` に相当（`.gitignore` に追加）
+
+## 5.3 dotnet format によるコードフォーマット
+
+### dotnet format とは
+
+> dotnet format は .NET の標準コードフォーマッターです。コードスタイルを統一し、チーム内のスタイル議論を排除します。
+
+Rust の rustfmt、Go の gofmt、Python の Ruff format、TypeScript の Prettier に相当します。
+
+### 実行してみる
+
+```bash
+# フォーマットチェック（CI 向け）
+$ dotnet format --verify-no-changes
+
+# 自動フォーマット
+$ dotnet format
+```
+
+### .editorconfig による設定
+
+`.editorconfig` ファイルでコーディングスタイルを定義できます。
+
+```ini
+root = true
+
+[*]
+indent_style = space
+indent_size = 4
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.cs]
+dotnet_sort_using_directives = true
+csharp_prefer_braces = true:warning
+```
+
+## 5.4 Roslyn アナライザによる静的解析
+
+### Roslyn アナライザとは
+
+> Microsoft.CodeAnalysis.Analyzers は .NET の公式リンターです。コンパイル時にコードの品質を自動チェックし、一般的なミスやアンチパターンを検出します。
+
+Rust の Clippy、TypeScript の ESLint、Python の Ruff、Go の golangci-lint に相当するツールです。
+
+### 導入方法
+
+```bash
+$ dotnet add package Microsoft.CodeAnalysis.Analyzers
+```
+
+ビルド時に自動的に静的解析が実行されます。
+
+```bash
+$ dotnet build
+```
+
+### 警告カテゴリ
+
+| カテゴリ | 説明 |
+|---------|------|
+| Design | 設計上の問題 |
+| Naming | 命名規則違反 |
+| Performance | パフォーマンスに影響するコード |
+| Reliability | 信頼性に関する問題 |
+| Security | セキュリティリスク |
+| Usage | API の誤用 |
+
+## 5.5 コードカバレッジ
+
+### coverlet
+
+C# のカバレッジツールとして `coverlet` があります。xUnit テストプロジェクトには既に含まれています。
+
+```bash
+# カバレッジ付きテスト実行
+$ dotnet test --collect:"XPlat Code Coverage"
+```
+
+HTML レポートを生成するには `reportgenerator` を利用します。
+
+```bash
+$ dotnet tool install -g dotnet-reportgenerator-globaltool
+$ reportgenerator -reports:"**/coverage.cobertura.xml" -targetdir:"coverage" -reporttypes:Html
+```
+
+## 5.6 SonarAnalyzer によるコード複雑度チェック
+
+### 認知的複雑度（Cognitive Complexity）
+
+SonarAnalyzer.CSharp には **S3776** ルールが内蔵されており、メソッドの認知的複雑度を計測できます。
+
+> 認知的複雑度とは、コードがどれだけ理解しにくいかを数値化した指標です。循環的複雑度（Cyclomatic Complexity）と異なり、ネストの深さやフロー制御の読みにくさも考慮します。
+
+| 複雑度の範囲 | 意味 |
+|-------------|------|
+| 1〜7 | 低複雑度: 管理しやすく、問題なし |
+| 8〜15 | 中程度の複雑度: リファクタリングを検討 |
+| 16〜25 | 高複雑度: リファクタリングが強く推奨される |
+| 26 以上 | 非常に高い複雑度: メソッドを分割する必要がある |
+
+### SonarAnalyzer.CSharp の導入
+
+NuGet パッケージとしてインストールします。
+
+```bash
+$ dotnet add package SonarAnalyzer.CSharp
+```
+
+`.csproj` にパッケージ参照が追加されます。
+
+```xml
+<ItemGroup>
+  <PackageReference Include="SonarAnalyzer.CSharp" Version="10.20.0.135146">
+    <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
+    <PrivateAssets>all</PrivateAssets>
+  </PackageReference>
+</ItemGroup>
+```
+
+### .editorconfig による設定
+
+`.editorconfig` に S3776 ルールの重大度を設定します。
+
+```ini
+[*.cs]
+# SonarAnalyzer: 認知的複雑度チェック
+# S3776 - Cognitive Complexity of methods should not be too high
+dotnet_diagnostic.S3776.severity = warning
+```
+
+他言語の複雑度チェック（Rust の Clippy `cognitive-complexity-threshold = 7`、PHP の PHPMD `reportLevel: 7`、Python の Ruff `max-complexity = 7`、TypeScript の ESLint `complexity: ["error", { max: 7 }]`）と同じ基準で、複雑度が高いメソッドを検出できます。
+
+### 実行してみる
+
+ビルド時に自動的にチェックが実行されます。
+
+```bash
+# 通常ビルド（警告として表示）
+$ dotnet build
+
+# 複雑度違反をエラーとして扱う（CI 向け）
+$ dotnet build -warnaserror:S3776
+```
+
+現在の FizzBuzz 実装では、各メソッドが短く単純なため、閾値を超えるメソッドはありません。
+
+### Cake への追加
+
+`build.cake` に Complexity タスクを追加します。
+
+```csharp
+Task("Complexity")
+    .IsDependentOn("Build")
+    .Does(() =>
+{
+    var exitCode = StartProcess("dotnet", new ProcessSettings
+    {
+        Arguments = "build FizzBuzz.sln --no-restore -warnaserror:S3776"
+    });
+    if (exitCode != 0)
+    {
+        throw new Exception("認知的複雑度チェックに失敗しました。メソッドの複雑度を下げてください。");
+    }
+    Information("認知的複雑度チェック: OK（全メソッドが閾値以下）");
+});
+
+Task("Check")
+    .IsDependentOn("Test")
+    .IsDependentOn("Complexity");
+```
+
+`dotnet dotnet-cake --target=Complexity` で複雑度チェックを単独実行、`dotnet dotnet-cake --target=Check` で全品質チェックをまとめて実行できます。
+
+### 他言語との比較
+
+| 言語 | 複雑度チェックツール | 設定 |
+|------|---------------------|------|
+| C# | SonarAnalyzer（S3776） | `.editorconfig: dotnet_diagnostic.S3776.severity = warning` |
+| Rust | Clippy（cognitive_complexity） | `clippy.toml: cognitive-complexity-threshold = 7` |
+| PHP | PHPMD | `reportLevel: 7` |
+| Java | PMD | `CyclomaticComplexity` |
+| Python | Ruff（McCabe） | `max-complexity = 7` |
+| TypeScript | ESLint | `complexity: ["error", { max: 7 }]` |
+| Ruby | RuboCop | `Metrics/CyclomaticComplexity` |
+| Go | golangci-lint（gocognit） | `.golangci.yml: gocognit.min-complexity: 7` |
+
+## 5.7 まとめ
+
+この章では以下を導入しました。
+
+| ツール | 役割 | 他言語の対応ツール |
+|--------|------|-------------------|
+| NuGet | パッケージ管理 | npm, Bundler, Cargo, pip |
+| dotnet format | コードフォーマット | rustfmt, gofmt, Prettier |
+| Roslyn アナライザ | 静的解析（リンター） | Clippy, ESLint, Ruff |
+| SonarAnalyzer（S3776） | コード複雑度チェック | Clippy cognitive_complexity, PHPMD, Ruff McCabe |
+| coverlet | カバレッジ計測 | cargo-tarpaulin, c8, SimpleCov |
+
+次章では、これらのツールを **タスクランナー**（Cake）でまとめて実行できるようにし、**CI/CD** パイプラインを構築します。