@k2works/claude-code-booster 6.1.0 → 6.3.0

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

@@ -1,391 +0,0 @@
----
-type: Article
-title: "第 5 章: パッケージ管理と静的解析"
-description: "前章では Conventional Commits によるコミットメッセージの規約を学びました。"
-tags: [article, getting-start-tdd, java]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 5 章: パッケージ管理と静的解析
-
-## 5.1 はじめに
-
-前章では Conventional Commits によるコミットメッセージの規約を学びました。この章では、**パッケージ管理** と **静的コード解析** を導入し、コードの品質を自動でチェックできるようにします。
-
-## 5.2 Gradle による依存関係管理
-
-### Gradle とは
-
-> Gradle とは、Java で記述されたビルドツール・依存関係管理ツールです。Gradle で扱う依存関係を dependencies として管理し、プロジェクトのビルドプロセスを自動化できます。
->
-> — Gradle Documentation
-
-第 1 部で JUnit 5 と JaCoCo はすでに導入しています。ここでは、静的コード解析ツールのための依存関係を追加します。
-
-### build.gradle の更新
-
-品質管理ツールを追加した `build.gradle` は以下のようになります。
-
-```groovy
-plugins {
-    id 'java'
-    id 'jacoco'
-    id 'checkstyle'
-    id 'pmd'
-    id 'com.github.spotbugs' version '6.0.7'
-}
-
-group = 'tdd.fizzbuzz'
-version = '0.1.0-SNAPSHOT'
-
-java {
-    toolchain {
-        languageVersion = JavaLanguageVersion.of(21)
-    }
-}
-
-repositories {
-    mavenCentral()
-}
-
-dependencies {
-    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.2'
-    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
-
-    // SpotBugs 関連
-    spotbugsPlugins 'com.h3xstream.findsecbugs:findsecbugs-plugin:1.12.0'
-}
-
-test {
-    useJUnitPlatform()
-
-    testLogging {
-        events("passed", "skipped", "failed")
-    }
-}
-
-jacoco {
-    toolVersion = '0.8.11'
-}
-
-pmd {
-    ruleSetFiles = files('config/pmd/ruleset.xml')
-    ruleSets = []
-}
-
-jacocoTestReport {
-    dependsOn test
-    reports {
-        xml.required = false
-        csv.required = false
-        html.outputLocation = layout.buildDirectory.dir('jacocoHtml')
-    }
-}
-```
-
-ビルドして依存関係をインストールします。
-
-```bash
-$ ./gradlew build
-```
-
-## 5.3 静的コード解析
-
-良いコードを書き続けるためには、コードの品質を維持していく必要があります。第 1 部ではテスト駆動開発によりプログラムを動かしながら品質を改善しました。出来上がったコードに対する品質チェックの方法として **静的コード解析** があります。
-
-### Checkstyle
-
-[Checkstyle](https://checkstyle.sourceforge.io/) はコーディング規約のチェックツールです。
-
-```bash
-$ ./gradlew checkstyleMain
-```
-
-### PMD
-
-[PMD](https://pmd.github.io/) は潜在的なバグやデッドコードを検出する静的解析ツールです。
-
-```bash
-$ ./gradlew pmdMain
-```
-
-### SpotBugs
-
-[SpotBugs](https://spotbugs.github.io/) はバグパターンを検出するツールです。セキュリティ脆弱性の検出には FindSecBugs プラグインを使用します。
-
-```bash
-$ ./gradlew spotbugsMain
-```
-
-### Checkstyle 設定ファイル
-
-プロジェクト固有のコーディング規約を定義する `config/checkstyle/checkstyle.xml` を作成します。
-
-```xml
-<?xml version="1.0"?>
-<!DOCTYPE module PUBLIC
-        "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
-        "https://checkstyle.org/dtds/configuration_1_3.dtd">
-
-<module name="Checker">
-    <property name="charset" value="UTF-8"/>
-
-    <!-- 抑制ルール -->
-    <module name="SuppressionFilter">
-        <property name="file" value="${config_loc}/suppressions.xml"/>
-    </module>
-
-    <!-- ファイルレベルのチェック -->
-    <module name="FileTabCharacter">
-        <property name="eachLine" value="true"/>
-    </module>
-
-    <!-- TreeWalker による AST 解析 -->
-    <module name="TreeWalker">
-        <!-- インデント -->
-        <module name="Indentation">
-            <property name="basicOffset" value="4"/>
-        </module>
-
-        <!-- 命名規則 -->
-        <module name="TypeName"/>
-        <module name="MethodName"/>
-        <module name="LocalVariableName"/>
-        <module name="MemberName"/>
-        <module name="ConstantName"/>
-
-        <!-- その他 -->
-        <module name="EmptyStatement"/>
-        <module name="EqualsHashCode"/>
-        <module name="MagicNumber">
-            <property name="ignoreHashCodeMethod" value="true"/>
-            <property name="ignoreAnnotation" value="true"/>
-        </module>
-    </module>
-</module>
-```
-
-## 5.4 マジックナンバーのリファクタリング
-
-Checkstyle の実行で、マジックナンバーの使用が指摘されます。**定数の抽出** リファクタリングで対応しましょう。
-
-### FizzBuzz.java のリファクタリング
-
-3 と 5 というマジックナンバーを定数に抽出します。
-
-#### Before
-
-```java
-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);
-}
-```
-
-#### After
-
-```java
-private static final int FIZZ_NUMBER = 3;
-private static final int BUZZ_NUMBER = 5;
-
-public String generate(int number) {
-    if (number % FIZZ_NUMBER == 0 && number % BUZZ_NUMBER == 0) {
-        return "FizzBuzz";
-    } else if (number % FIZZ_NUMBER == 0) {
-        return "Fizz";
-    } else if (number % BUZZ_NUMBER == 0) {
-        return "Buzz";
-    }
-    return String.valueOf(number);
-}
-```
-
-### Main.java のリファクタリング
-
-100 というマジックナンバーも定数に抽出します。
-
-```java
-public class Main {
-    private static final int MAX_NUMBER = 100;
-
-    public static void main(String[] args) {
-        FizzBuzz fizzBuzz = new FizzBuzz();
-        fizzBuzz.printFizzBuzz(MAX_NUMBER);
-    }
-}
-```
-
-### テストコードの抑制ルール
-
-テストコードではマジックナンバーや日本語メソッド名を許容するため、`config/checkstyle/suppressions.xml` で抑制ルールを設定します。
-
-```xml
-<suppressions>
-    <suppress files=".*Test\.java$" checks="MagicNumber"/>
-    <suppress files=".*Test\.java$" checks="MethodName"/>
-</suppressions>
-```
-
-リファクタリング後もテストが通ることを確認します。
-
-```
-BUILD SUCCESSFUL
-8 tests passed
-```
-
-## 5.5 コードフォーマット
-
-良いコードであるためにはフォーマットも大切な要素です。
-
-> 優れたソースコードは「目に優しい」ものでなければいけない。
->
-> — リーダブルコード
-
-Checkstyle の設定でインデントチェックを有効にしているため、フォーマットの崩れも自動で検出できます。
-
-```bash
-$ ./gradlew checkstyleMain
-```
-
-## 5.6 コードカバレッジ
-
-静的コード解析による品質の確認はできました。動的なテストに関しては **コードカバレッジ** を確認する必要があります。
-
-> コード網羅率（Code coverage）は、ソフトウェアテストで用いられる尺度の 1 つである。プログラムのソースコードがテストされた割合を意味する。
->
-> — ウィキペディア
-
-JaCoCo のカバレッジレポートを生成します。
-
-```bash
-$ ./gradlew jacocoTestReport
-```
-
-テスト実行後に `build/jacocoHtml` フォルダが作成されます。その中の `index.html` を開くとカバレッジ状況を確認できます。
-
-## 5.7 コード複雑度のチェック
-
-静的コード解析では、コーディング規約やバグパターンだけでなく、**コードの複雑度** もチェックできます。PMD のカスタムルールセットを使って、メソッドの複雑度を制限しましょう。
-
-### 循環的複雑度（Cyclomatic Complexity）
-
-> 循環的複雑度（サイクロマティック複雑度）とは、ソフトウェア測定法の一つであり、コードがどれぐらい複雑であるかをメソッド単位で数値にして表す指標。
-
-本プロジェクトでは、循環的複雑度を **7 以下** に制限しています。
-
-| 複雑度の範囲 | 意味 |
-|-------------|------|
-| 1〜10 | 低複雑度：管理しやすく、問題なし |
-| 11〜20 | 中程度の複雑度：リファクタリングを検討 |
-| 21〜50 | 高複雑度：リファクタリングが強く推奨される |
-| 51 以上 | 非常に高い複雑度：コードを分割する必要がある |
-
-### 認知的複雑度（Cognitive Complexity）
-
-> 認知的複雑度（Cognitive Complexity）は、プログラムを読む人の認知負荷を測るための指標。コードの構造が「どれだけ頭を使う必要があるか」を定量的に評価する。循環的複雑度とは異なり、制御構造のネストやコードの流れの読みやすさに重点を置いている。
-
-本プロジェクトでは、認知的複雑度を **4 以下** に制限しています。
-
-| 複雑度の範囲 | 意味 |
-|-------------|------|
-| 0〜4 | 理解が非常に容易：リファクタリング不要 |
-| 5〜14 | 中程度の難易度：改善が必要な場合もある |
-| 15 以上 | 理解が困難：コードの簡素化を検討するべき |
-
-### PMD ルールセットの設定
-
-`config/pmd/ruleset.xml` にコード複雑度のルールを定義します。
-
-```xml
-<?xml version="1.0"?>
-<ruleset name="Custom Rules"
-         xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
-         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-         xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
-             https://pmd.sourceforge.io/ruleset_2_0_0.xsd">
-
-    <description>プロジェクト用 PMD ルールセット</description>
-
-    <!-- 基本ルール -->
-    <rule ref="category/java/bestpractices.xml">
-        <exclude name="JUnitTestContainsTooManyAsserts"/>
-    </rule>
-    <rule ref="category/java/errorprone.xml"/>
-    <rule ref="category/java/codestyle.xml">
-        <exclude name="AtLeastOneConstructor"/>
-        <exclude name="OnlyOneReturn"/>
-        <exclude name="LocalVariableCouldBeFinal"/>
-        <exclude name="MethodArgumentCouldBeFinal"/>
-        <exclude name="ShortVariable"/>
-        <exclude name="LongVariable"/>
-        <exclude name="ShortMethodName"/>
-        <exclude name="ShortClassName"/>
-        <exclude name="CommentDefaultAccessModifier"/>
-    </rule>
-
-    <!-- コード複雑度 -->
-    <rule ref="category/java/design.xml/CyclomaticComplexity">
-        <properties>
-            <property name="classReportLevel" value="80"/>
-            <property name="methodReportLevel" value="7"/>
-        </properties>
-    </rule>
-    <rule ref="category/java/design.xml/CognitiveComplexity">
-        <properties>
-            <property name="reportLevel" value="4"/>
-        </properties>
-    </rule>
-    <rule ref="category/java/design.xml/NPathComplexity">
-        <properties>
-            <property name="reportLevel" value="200"/>
-        </properties>
-    </rule>
-</ruleset>
-```
-
-`build.gradle` に PMD のルールセットファイルを参照する設定を追加します。
-
-```groovy
-pmd {
-    ruleSetFiles = files('config/pmd/ruleset.xml')
-    ruleSets = []
-}
-```
-
-### 複雑度チェックの実行
-
-```bash
-$ ./gradlew pmdMain
-```
-
-### 複雑度チェックの効果
-
-コード複雑度の制限により、以下の効果が得られます。
-
-- **可読性向上** — 小さなメソッドは理解しやすい
-- **保守性向上** — 変更の影響範囲が限定される
-- **テスト容易性** — 個別機能のテストが簡単
-- **自動品質管理** — 複雑なコードの混入を自動防止
-
-現在の FizzBuzz の `generate` メソッドは循環的複雑度が 4 で、制限値 7 以内に収まっています。第 3 部でオブジェクト指向設計を進める際も、この制限を意識してコードを書いていきます。
-
-## 5.8 まとめ
-
-この章では、パッケージ管理と静的コード解析を導入しました。
-
-| ツール | 用途 | コマンド |
-|--------|------|---------|
-| Gradle | 依存関係管理・ビルド | `./gradlew build` |
-| Checkstyle | コーディング規約チェック | `./gradlew checkstyleMain` |
-| PMD | 静的コード解析・複雑度チェック | `./gradlew pmdMain` |
-| SpotBugs | バグパターン検出 | `./gradlew spotbugsMain` |
-| JaCoCo | コードカバレッジ | `./gradlew jacocoTestReport` |
-
-次の章では、これらのタスクをまとめて実行できるタスクランナーと、自動化について解説します。

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

@@ -1,281 +0,0 @@
----
-type: Article
-title: "第 6 章: タスクランナーと CI/CD"
-description: "前章では静的コード解析ツールとコードカバレッジを導入しました。"
-tags: [article, getting-start-tdd, java]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 6 章: タスクランナーと CI/CD
-
-## 6.1 はじめに
-
-前章では静的コード解析ツールとコードカバレッジを導入しました。テストの実行、静的解析、フォーマットチェック、カバレッジ計測と、様々なコマンドを使えるようになりましたが、毎回それぞれのコマンドを覚えて実行するのは面倒です。
-
-この章では **タスクランナー** を使ってこれらのタスクをまとめて実行できるようにし、さらに **自動化** によってファイル変更時にテストが自動実行される環境を構築します。
-
-## 6.2 タスクランナー
-
-### タスクランナーとは
-
-> タスクランナーとは、アプリケーションのビルドなど、一定の手順で行う作業をコマンド一つで実行できるように予めタスクとして定義したものです。
->
-> — Gradle Documentation
-
-Java のタスクランナーは Gradle です。`build.gradle` にカスタムタスクを定義することで、複数の作業をコマンド一つで実行できます。
-
-### カスタムタスクの定義
-
-`build.gradle` に以下のカスタムタスクを追加します。
-
-#### TDD 用テストタスク
-
-```groovy
-task tdd(type: Test) {
-    useJUnitPlatform()
-    testLogging {
-        events "passed", "skipped", "failed"
-        exceptionFormat "full"
-    }
-    outputs.upToDateWhen { false }
-}
-```
-
-`outputs.upToDateWhen { false }` により、コードに変更がなくても毎回テストを実行します。
-
-#### 品質チェックタスク
-
-```groovy
-task qualityCheck {
-    dependsOn 'checkstyleMain', 'checkstyleTest', 'pmdMain', 'pmdTest', 'spotbugsMain', 'spotbugsTest'
-    description 'Run all quality checks'
-    group 'verification'
-}
-```
-
-#### 全チェックタスク
-
-```groovy
-task fullCheck {
-    dependsOn 'test', 'qualityCheck', 'jacocoTestReport'
-    description 'Run all tests and quality checks'
-    group 'verification'
-}
-```
-
-### タスクの確認と実行
-
-登録されたタスクを確認します。
-
-```bash
-$ ./gradlew tasks --group verification
-
-Verification tasks
-------------------
-check - Runs all checks.
-checkstyleMain - Run Checkstyle analysis for main classes.
-checkstyleTest - Run Checkstyle analysis for test classes.
-fullCheck - Run all tests and quality checks
-pmdMain - Run PMD analysis for main classes.
-pmdTest - Run PMD analysis for test classes.
-qualityCheck - Run all quality checks
-spotbugsMain - Run SpotBugs analysis for main classes.
-spotbugsTest - Run SpotBugs analysis for test classes.
-test - Runs the unit tests.
-tdd - Runs the unit tests.
-```
-
-各タスクを実行します。
-
-```bash
-# TDD 用テスト
-$ ./gradlew tdd
-
-# 品質チェック
-$ ./gradlew qualityCheck
-
-# 全チェック（テスト + 品質チェック + カバレッジ）
-$ ./gradlew fullCheck
-```
-
-## 6.3 タスクの自動化
-
-### Gradle Continuous Build
-
-良いコードを書くためのタスクをまとめることができました。さらに自動で実行できるようにしましょう。Gradle の **Continuous Build** 機能を使うと、ファイルの変更を監視して自動的にテストを実行してくれます。
-
-```bash
-$ ./gradlew test --continuous
-```
-
-このコマンドを実行すると、ソースファイルを保存するたびにテストが自動実行されます。
-
-### 自動テストの効果
-
-自動テストの効果を確認するために、わざとコードを壊してみましょう。
-
-```java
-// わざとテストを失敗させる変更
-if (number % FIZZ_NUMBER == 0 && number % BUZZ_NUMBER == 0) {
-    return "FizzBuzzBuzz";  // わざと間違えてみる
-}
-```
-
-変更を保存すると、即座にテストが実行されて失敗が検出されます。コードを元に戻すと、テストが再び通ります。
-
-### IDE の Auto Test 機能
-
-IntelliJ IDEA や VS Code 等の IDE の **Auto Test** 機能を使うことで、ファイル変更時に自動でテストが実行されるように設定することも可能です。
-
-## 6.4 GitHub Actions による CI/CD
-
-### CI/CD とは
-
-ローカルでの自動化に加えて、リポジトリにプッシュするたびに自動でテストと品質チェックを実行する仕組みが **CI/CD（継続的インテグレーション / 継続的デリバリー）** です。
-
-> 継続的インテグレーション（CI）は、チームメンバーが頻繁にコードを統合するプラクティスです。各統合はビルドとテストの自動化によって検証されます。
-
-GitHub が提供する **GitHub Actions** を使って CI パイプラインを構築しましょう。
-
-### ワークフローファイルの作成
-
-`.github/workflows/java-ci.yml` を作成します。
-
-```yaml
-name: Java CI
-
-on:
-  push:
-    branches: [main, develop]
-    paths:
-      - 'apps/java/**'
-      - 'ops/nix/environments/java/**'
-      - 'flake.nix'
-      - 'flake.lock'
-  pull_request:
-    branches: [main]
-    paths:
-      - 'apps/java/**'
-      - 'ops/nix/environments/java/**'
-      - 'flake.nix'
-      - 'flake.lock'
-
-permissions:
-  contents: read
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Checkout the repository
-        uses: actions/checkout@v4
-
-      - name: Install Nix
-        uses: cachix/install-nix-action@v30
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-
-      - name: Cache Nix store
-        uses: actions/cache@v4
-        with:
-          path: /tmp/nix-cache
-          key: ${{ runner.os }}-nix-java-${{ hashFiles('flake.lock', 'ops/nix/environments/java/shell.nix') }}
-          restore-keys: |
-            ${{ runner.os }}-nix-java-
-
-      - name: Run tests
-        run: nix develop .#java --command bash -c "cd apps/java && ./gradlew test"
-
-      - name: Run quality checks
-        run: nix develop .#java --command bash -c "cd apps/java && ./gradlew qualityCheck"
-
-      - name: Generate coverage report
-        run: nix develop .#java --command bash -c "cd apps/java && ./gradlew jacocoTestReport"
-
-      - name: Upload test results
-        if: always()
-        uses: actions/upload-artifact@v4
-        with:
-          name: test-results
-          path: apps/java/build/reports/tests/
-
-      - name: Upload coverage report
-        if: always()
-        uses: actions/upload-artifact@v4
-        with:
-          name: coverage-report
-          path: apps/java/build/jacocoHtml/
-```
-
-### ワークフローの解説
-
-| 設定項目 | 内容 |
-|---------|------|
-| トリガー | `main`/`develop` ブランチへの push、`main` への PR |
-| パスフィルター | `apps/java/**` および Nix 環境定義の変更時に実行 |
-| Nix | `cachix/install-nix-action` でインストール |
-| 環境 | `nix develop .#java` でローカルと同一の JDK・Gradle を使用 |
-| テスト | `./gradlew test` でユニットテスト実行 |
-| 品質チェック | `./gradlew qualityCheck` で静的解析実行 |
-| カバレッジ | `./gradlew jacocoTestReport` でレポート生成 |
-| アーティファクト | テスト結果とカバレッジレポートを保存 |
-
-Nix を使う最大のメリットは、**ローカル開発環境と CI 環境が完全に同一になる** ことです。JDK や Gradle のバージョン差異による「ローカルでは通るが CI では失敗する」問題を根本的に防げます。
-
-### CI パイプラインの流れ
-
-```
-git push
-  → GitHub Actions トリガー
-    → Nix インストール
-      → nix develop .#java（JDK 21 + Gradle 環境）
-        → テスト実行
-          → 品質チェック（Checkstyle + PMD + SpotBugs）
-            → カバレッジレポート生成
-              → アーティファクトアップロード
-```
-
-これにより、ローカルでのテストを忘れた場合でも、プッシュ時に自動で品質チェックが実行されます。プルリクエストでは全チェックが通らないとマージできないようにすることも可能です。
-
-## 6.5 ソフトウェア開発の三種の神器と CI/CD
-
-ここまでで、ソフトウェア開発の三種の神器がすべて揃いました。
-
-| 神器 | ツール | 用途 |
-|------|--------|------|
-| バージョン管理 | Git + Conventional Commits | 変更履歴の管理 |
-| テスティング | JUnit 5 + JaCoCo | テスト駆動開発 + カバレッジ |
-| 自動化 | Gradle タスクランナー + GitHub Actions | 品質チェックの自動実行 + CI/CD |
-
-これらのツールにより、**動作するきれいなコード** を継続的に書き続けることができる環境が整いました。
-
-```
-./gradlew test --continuous
-```
-
-次の開発からはこのコマンドを最初に実行すれば、コードを書くことに集中できるようになります。
-
-## 6.6 まとめ
-
-第 2 部（第 4〜6 章）を通じて、ソフトウェア開発の三種の神器を整備しました。
-
-| 章 | テーマ | 学んだこと |
-|----|--------|-----------|
-| 4 | バージョン管理 | Conventional Commits、コミットタイプ |
-| 5 | パッケージ管理と静的解析 | Checkstyle、PMD、SpotBugs、JaCoCo |
-| 6 | タスクランナーと CI/CD | カスタムタスク、Continuous Build、GitHub Actions |
-
-### TDD 開発ワークフロー
-
-```
-1. ./gradlew test --continuous  ← 最初に実行
-2. テストを書く（Red）
-3. 実装する（Green）
-4. リファクタリングする（Refactor）
-5. git commit -m 'feat: ...'  ← Conventional Commits
-6. 2 に戻る
-```
-
-次の第 3 部では、FizzBuzz に追加仕様を導入し、オブジェクト指向設計のテクニックを学びます。