開発ワークフロー

このページでは、Fess の開発における標準的なワークフローを説明します。機能追加、バグ修正、テスト、コードレビューなど、開発作業の進め方を学ぶことができます。

開発の基本フロー

Fess の開発は、以下のような流れで進めます：

1. Issue の確認・作成
   ↓
2. ブランチの作成
   ↓
3. コーディング
   ↓
4. ローカルテストの実行
   ↓
5. コミット
   ↓
6. プッシュ
   ↓
7. プルリクエストの作成
   ↓
8. コードレビュー
   ↓
9. レビューフィードバックへの対応
   ↓
10. マージ

各ステップについて詳しく説明します。

Step 1: Issue の確認・作成

開発を始める前に、GitHub の Issue を確認します。

既存の Issue を確認

Fess の Issue ページにアクセス
取り組みたい Issue を探す
Issue にコメントして、作業を開始する旨を伝える

Tip

初めての貢献の場合は、good first issue ラベルが付いた Issue から始めることをお勧めします。

新しい Issue の作成

新しい機能やバグ修正の場合は、Issue を作成します。

New Issue をクリック
Issue のテンプレートを選択
必要な情報を記入：
- タイトル: 簡潔で分かりやすい説明
- 説明: 詳細な背景、期待される動作、現在の動作
- 再現手順: バグの場合
- 環境情報: OS、Java バージョン、Fess バージョンなど
Submit new issue をクリック

Issue の記載例

以下は Issue を作成する際の記載例です。

バグレポート:

## 問題の説明
バグの簡潔な説明

## 再現手順
1. ...
2. ...
3. ...

## 期待される動作
本来どうあるべきか

## 実際の動作
現在どうなっているか

## 環境
- OS:
- Java バージョン:
- Fess バージョン:

機能リクエスト:

Step 2: ブランチの作成

作業用のブランチを作成します。

ブランチ命名規則

ブランチ名は、以下の形式に従います：

type の種類:

feature: 新機能の追加
fix: バグ修正
refactor: リファクタリング
docs: ドキュメントの更新
test: テストの追加・修正

例:

ブランチの作成手順

最新の main ブランチを取得：
```
git checkout main
git pull origin main
```

新しいブランチを作成：

ブランチが作成されたことを確認：
```
git branch
```

Step 3: コーディング

機能の実装やバグ修正を行います。

コーディング規約

Fess では、以下のコーディング規約に従います。

基本的なスタイル

インデント: スペース 4 つ
行の長さ: 140 文字以内を推奨
エンコーディング: UTF-8
改行コード: LF（Unix スタイル）

命名規則

クラス名: PascalCase（例: SearchService）
メソッド名: camelCase（例: executeSearch）
定数: UPPER_SNAKE_CASE（例: MAX_SEARCH_SIZE）
変数: camelCase（例: searchResults）

Javadoc: public なクラスとメソッドには必須
実装コメント: 複雑なロジックには日本語または英語で説明を追加

例:

/**
 * 検索を実行します。
 *
 * @param query 検索クエリ
 * @return 検索結果
 */
public SearchResponse executeSearch(String query) {
    // クエリの正規化
    String normalizedQuery = normalizeQuery(query);

    // 検索の実行
    return searchEngine.search(normalizedQuery);
}

null の扱い

可能な限り null を返さない
Optional の使用を推奨
null チェックは明示的に行う

例:

// 良い例
public Optional<User> findUser(String id) {
    return userRepository.findById(id);
}

// 避けるべき例
public User findUser(String id) {
    return userRepository.findById(id);  // null の可能性
}

例外処理

例外は適切にキャッチして処理する
ログ出力を行う
ユーザーに分かりやすいメッセージを提供

例:

ログ出力

適切なログレベルを使用します：

ERROR: エラー発生時
WARN: 警告すべき状況
INFO: 重要な情報
DEBUG: デバッグ情報
TRACE: 詳細なトレース情報

例:

開発中のテスト

開発中は、以下の方法でテストします：

ローカル実行

IDE で org.codelibs.fess.FessBoot クラスを実行し、動作を確認します。詳細はビルドとテストを参照してください。

デバッグ実行

IDE のデバッガーを使用して、コードの動作を追跡します。

単体テストの実行

変更に関連するテストを実行します：

詳細はビルドとテストを参照してください。

Step 4: ローカルテストの実行

コミット前に、必ずテストを実行します。

単体テストの実行

統合テストの実行

コードフォーマットのチェック

すべてのチェックを実行

Step 5: コミット

変更をコミットします。

コミットメッセージの規約

コミットメッセージは、以下の形式に従います：

type の種類:

feat: 新機能
fix: バグ修正
docs: ドキュメントのみの変更
style: コードの意味に影響しない変更（フォーマットなど）
refactor: リファクタリング
test: テストの追加・修正
chore: ビルドプロセスやツールの変更

例:

コミット手順

変更をステージング：
```
git add .
```

コミット：

コミット履歴を確認：
```
git log --oneline
```

コミットの粒度

1 つのコミットには 1 つの論理的な変更を含める
大きな変更は複数のコミットに分割する
コミットメッセージは分かりやすく、具体的に

Step 6: プッシュ

ブランチをリモートリポジトリにプッシュします。

初回プッシュの場合：

Step 7: プルリクエストの作成

GitHub でプルリクエスト（PR）を作成します。

PR の作成手順

Fess リポジトリにアクセス
Pull requests タブをクリック
New pull request をクリック
ベースブランチ（main）と比較ブランチ（作業ブランチ）を選択
Create pull request をクリック
PR の内容を記入（テンプレートに従う）
Create pull request をクリック

PR の記載例

以下は PR を作成する際の推奨フォーマットです。

## 変更内容
この PR で何を変更したか

## 関連 Issue
Closes #123

## 変更の種類
- [ ] 新機能
- [ ] バグ修正
- [ ] リファクタリング
- [ ] ドキュメント更新
- [ ] その他

## テスト方法
この変更をどのようにテストしたか

## チェックリスト
- [ ] コードは動作する
- [ ] テストを追加した
- [ ] ドキュメントを更新した
- [ ] コーディング規約に従っている