Linked Issueの活用

Linked Issueを活用することで、特定の不具合に対する修正を明確に関連付けることができます。これは、プルリクエストの説明の中で指定します。そうすると、プルリクエストがその要件に適切に対応しているかをレビューするようになります。

ただし、Issueの書き方が重要になります。

書き方

現在のところ、GitHubとGitLab、Jira、Linearに対応しています。

GitHub

下記のような書き方で指定します。

fixes #123
closes #123
resolves #123
またはURL

GitLab

下記のような書き方で指定します。

closes #123
fixes #123
またはURL

Jira/Linear

チケットのURLで指定します。

Issueの書き方

リンクするIssueについては、下記の注意点を踏まえて書いてください。

タイトル

目標を明確に示す、説明的かつ技術的なタイトルが良いです。

良い例
- 設定フローにPrismaLintの統合を追加する
- ユーザー認証における競合状態の修正
- GraphQLクエリのキャッシュを実装する
悪い例
- バグの修正
- コードの更新
- パフォーマンスの向上

説明文

わかりやすい技術的背景と、包括的な説明を記述してください。

問題の定義

変更すべき点を明確に説明する
影響を受ける部品に関する技術的な詳細を含む
既知の場合は、特定のファイルや関数を参照する

期待される解決策

望ましい実施方法の概要
関連する場合は、コード例や擬似コードを含める
具体的な受け入れ基準をリストアップする

説明文の例です。

問題:
システムはデプロイ前にPrismaスキーマファイルの検証を行わないため、実行時エラーが発生する可能性がある。

解決策:
構成フローにPrismaLintを統合し、以下の機能を実現する:

- PRチェック時にスキーマファイルを検証
- 一貫した命名規則を強制適用
- Prismaの一般的なアンチパターンを防止

影響を受けるコンポーネント:
- 構成検証パイプライン
- CI/CDワークフロー
- スキーマ検証ロジック

受け入れ基準:
- [ ] PrismaLintがすべてのPRチェックで実行される
- [ ] 検証に失敗したPRはマージがブロックされる
- [ ] スキーマの問題に対する明確なエラーメッセージが表示される

用語

課題とPRの間で、一貫した用語を使用します。

良い例
- 同じ専門用語を一貫して使う
- 参照コンポーネントの正確な名称
- 一貫した命名パターンを維持する
悪い例
- 同じコンポーネントに異なる用語を混ぜる
- 曖昧で専門的でない言葉を使う
- 一貫性のない大文字と小文字

リンク

複数も指定可能です。

This PR addresses:
- Fixes #123
- Closes #456
- Resolves https://jira.company.com/browse/PROJ-789

例

以下の画像のように、要件が満たされているかどうかを一覧表でまとめます。また、レビュー時に要件が満たされているかどうかの視点が加わります。

✅ : IssueがPRで取り上げられている
❌ : IssueがPRで取り上げられていない
❓ : 取り上げられているか不明

まとめ

AIコーディングエージェントを利用している場合、タスクのスコープをなるべく小さくしたほうが正確なコーディングを行える傾向があるかと思います。Issue駆動で開発を行う際に、こうやって明確なスコープと目的を書くことで、レビューの精度も上げられそうです。

ぜひ、CodeRabbitを活用してください。

Linked Issues - CodeRabbit