観点別にレビューを実施する
GitHub Copilotはコードレビューにおいても有用です。しかし、その能力を最大限に引き出すためには、レビューを依頼する方法、特に「レビュー観点の与え方」に工夫が求められます。
なぜレビュー観点を1度にまとめて与えてはいけないのか
通常、コードレビューは品質、パフォーマンス、セキュリティなどの多岐にわたる観点から行われます。
これらの観点をすべて含んだ長大なプロンプトを1度にGitHub Copilotへ与えてしまうと、AIが指示の全体像を把握しきれなかったり、特に重要な観点を見失ってしまったりする可能性があります。
これは、一度に大量の情報を与えられるとAIが個々の指示の重要度を判断しきれなくなる特性に起因します。
結果として個々の観点に対するレビューの精度が低下し、網羅的でない表面的なフィードバックに留まってしまうことがあります。
レビュー観点を分割し、連続で実行する
この問題を解決する効果的なアプローチが、「レ ビュー観点ごとにプロンプトを分割し、それらを連続で実行する」方法です。
たとえば、「コードの可読性」「例外処理の適切さ」「パフォーマンス」といった観点ごとに個別のプロンプトを作成します。
これによりAIは一度に1つのタスクに集中できるため、各観点においてより深く、精度の高いレビューを行うことができます。
しかし、観点ごとに分割したプロンプトを手動で1つずつ実行するのは非効率です。
そこでPromptisというプロンプトの連続実行を支援するVisual Studio CodeのExtensionを使用します。
Promptisを使えば、あらかじめ用意した複数のレビュー観点プロンプトを1回の操作で順番に実行でき、レビュープロセスを効率化しつつ、レビューの質も高めることが可能です。
レビュー観点のプロンプトはファイルとして作成します。
これはAIにとって読みやすいMarkdown形式というだけであり、Visual Studio Codeのプロンプトファイルとは異なるものです。
PromptisはVisual Studio Codeのプロンプトファイルの構造をサポートしていません。
以下は、一般的なJavaのコード品質を保っているかというレビュー観点の例です。
コードを評価して改善案をMarkdown表形式で示してください。
表以外は表示しないでください
## 表
観点、結果(⚪︎,×,△,-)、改善点
## rule
- なるべく再代入は避け、finalを活用すること
- なるべく引数の状態を変えないこと
- コレクションのように型パラメーターを取るクラスを使用する場合は適切な型をバインドしていること
- 計算式の途中でのインクリメント・デクリメントを行っていないこと
- スーパークラスと同名のフィールドをサブクラスで定義していないこと
- コレクションや配列の戻り値でnullを返していないこと
- コンストラクタ内で自分自身のインスタン スメソッドを呼び出していないこと
- メソッドの引数と戻り値が適切に定義されていること
- ループの終了条件を最適化していること（例:length を毎回計算しない）
- 不要なループのネストを避けていること
- 適切な場合、拡張 for ループ（for-each）を使用していること
- 頻繁に実行される条件分岐で、最も可能性の高い条件を先に評価していること
- switch 文の使用が適切か、default ケースの位置は適切か
- 不要な再帰呼び出しを避けていること
- 複雑な条件分岐が適切に管理されていること
- 文字列操作にはApache Commons Langを使用していること
- 重複コードが存在していないこと
- ハードコードされた値や定数が適切に管理されていること
- 不要な複雑性がないこと（過度に複雑な条件分岐など）
- マジックナンバーや文字列リテラルが適切に定数化されていること
- 不要なコードやデッドコードが残っていないこと
- 名前と値が同じ定数を作っていないこと
- メソッドのオーバーロードはオプションの省略用途のみに限定していること
- インナークラスやstaticにネストしたクラス、匿名クラスを作りすぎていないこと
- 外部からの入力値は共通部品を用いてチェックしていること
- 計算の誤差が許されない場合はBigDecimalを使用していること
...
作成したレビュー観点の複数のファイルを一括実行してレビューする方法は、Promptisのドキュメントを参照してください。