観点別にレビューを実施する
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のドキュメントを参照してください。