GitHub Copilot Chat を使ったワンフレーズコードレビュー

はじめに

こんにちは。今年2023年にココネに入社しましたサーバエンジニアのOです。
@rougan さんからバトンを受け取りアドベントカレンダー14日目の記事となります。

別の記事にもありますが、弊社では GitHub Copilot の導入が進んでおります。
中でも GitHub Copilot Chat はよく使っており、既に並のエンジニア以上のコーディング力があると感じています。
反面、指示を自然言語で行うため、使いこなすには他のエンジニアに対しての指示書を書くようなスキルが求められます。

本記事では そのような面倒くささを排除し毎度コードチェックに使えるフレーズ5選 を紹介したいと思います。

こんな方におすすめ

• コードの良し悪しがいまいちピンと来てない初級者〜中級者の方
• 大量のプルリクエストのレビューを効率的に行いたい方
• 文書を考えて指示を与えるのがめんどくさい方

前提

• Visual Studio Code + GitHub Copilot Chat Extension
• Go言語
• 出来上がったコードに対してのコードレビュー用途で使います
• VSCodeの機能拡張のサイドバーから使用 (レビュー対象コードを選択しサイドバーのフォームにフレーズを打ち込む形で使います)

使用イメージ

フレーズ5選

• 改善するべき箇所はありますか
• 複雑なロジックをシンプルに
• 脆弱性はありますか
• おかしな命名を指摘して
• コメントは適切ですか

1. 改善するべき箇所はありますか

概要

• 一般的に悪いとされるコード全般を指摘してくれます。
• これだけでも実行しておくと良いです。

回答例

この関数は、いくつか改善できる箇所があります。

1. 関数の長さ: この関数は非常に長く、多くの処理を含んでいます。これらの処理をより小さな関数に分割することで、コードの可読性とメンテナンス性を向上させることができます。
2. エラーハンドリング: この関数では、多くの場所でエラーチェックを行い、エラーが発生した場合には即座にエラーメッセージを返しています。これは良い習慣ですが、エラーハンドリングを一箇所にまとめることで、コードの可読性をさらに向上させることができます。
3. コメント: コードにはコメントが少なく、何をしているのかを理解するのが難しい部分があります。各処理ブロックの目的や、複雑なロジックの説明を追加することで、他の開発者がコードを理解しやすくなります。
4. マジックナンバー: コード内にはマジックナンバー（直接的な数値）が存在します。これらの数値を定数に置き換えることで、コードの可読性と保守性を向上させることができます。
5. テスト: この関数のテストが存在しない場合、適切なユニットテストを作成することをお勧めします。テストを作成することで、関数が期待通りに動作することを確認し、将来的なバグを防ぐことができます。

2. 複雑なロジックをシンプルに

概要

• 中級レベルのエンジニアもやりがちな、1つの関数が長かったり条件判定のネストが深くなっている部分の指摘および修正をしてくれます。
• これもコードレビューに提出する前に自分で実行してもらうとレビュアーが助かります 。

回答例

この関数は非常に長く、多くのロジックを含んでいます。これをシンプルにするためには、関数をより小さな部分に分割することが有効です。以下に、この関数をいくつかの小さな関数に分割する一例を示します。
(以下、適切な粒度の関数に分割されたコードが出てきます)

3. 脆弱性はありますか

概要

• バリデーション、インジェクション攻撃、リソースの開放忘れなどについて指摘してくれます。
• 対策済みの箇所について指摘されることもよくあるので、自分の想定外の指摘がないかを見ると良いでしょう。

回答例

この関数はGo言語で書かれており、一般的な脆弱性に対する防御策が適用されているように見えます。具体的には、ユーザーからの入力を直接使用する前に適切な検証が行われています。
ただし、以下の点に注意するとさらに安全性が向上するでしょう。

1. エラーハンドリング: この関数では、多くの場所でエラーチェックを行い、エラーが発生した場合には即座にエラーメッセージを返しています。これは良い習慣ですが、エラーメッセージが詳細すぎると、攻撃者にシステムの情報を漏らす可能性があります。エラーメッセージはユーザーフレンドリーである一方で、システムの詳細を隠蔽するようにすると良いでしょう。
2. ロックの解放: ＊＊＊.Lock と ***.Unlock の間で何らかのエラーが発生した場合、ロックが解放されずにリソースリークを引き起こす可能性があります。Goの defer ステートメントを使用して、関数の終了時に必ずロックが解放されるようにすると良いでしょう。
3. SQLインジェクション: このコードでは、データベースに対するクエリが行われています。ユーザーからの入力をそのままクエリに使用していないか確認してください。ユーザーからの入力をそのままクエリに使用すると、SQLインジェクション攻撃のリスクがあります。
4. パラメータチェック: 関数のパラメータが適切に検証されているか確認してください。不適切なパラメータが渡された場合に適切なエラーメッセージを返すようにすると、システムの安全性が向上します。

以上の点を確認し、必要に応じて修正することで、システムの安全性を向上させることができます。

4. おかしな命名を指摘して

概要

• 関数名や変数名について、命名の改善箇所を提案してくれます。
• 個人的に命名が苦手なので指摘からの気づきが多いです。

回答例

このGoのコードを見ると、一部の変数や関数の命名が一般的なGoの命名規則に完全に従っていないように見えます。以下にいくつかの例を挙げます。

1. ***lock：この変数名は、単語間にキャメルケース（例：***Lock）を使用することで、読みやすさを向上させることができます。
2. UserHogeHogeRepository.GetHogeHogeListAll：この関数名は長すぎる可能性があります。より短く、しかし意味のある名前を検討してみてください。
3. ***ItemInfo：この変数名は抽象的すぎる可能性があります。より具体的な名前を使用することを検討してみてください。

以上の点を考慮に入れて、コードの可読性と保守性を向上させるために、適切な命名を検討してみてください。

5. コメントは適切ですか

概要

• コメントの過不足や形式について指摘してくれます。

回答例

このGoのコードのコメントは全体的に適切ですが、いくつかの改善点があります。

1. 関数の説明: この関数が具体的に何を行うのか、どのようなパラメータを受け取り、何を返すのかを詳細に説明すると更に良いです。
2. ステップの説明: コードの各ステップにコメントがありますが、それらは何を行っているのかを説明するよりも、何を行うために存在しているのか（その目的）を説明する方が理解しやすいです。
3. Goのドキュメンテーションコメント: Goでは、公開される関数、型、定数などにはドキュメンテーションコメントを書くことが推奨されています。これは、そのアイテムの直前に//で始まるコメントで、そのアイテムの名前で始まります。

以上の点を考慮に入れると、コメントは適切ですが、いくつかの改善点があります。

感想

• コードレビューの際に指摘されることが多い事項を自らチェックできるので積極的に使って頂きたいです。
• 悪いコードに対しては納得できる指摘が多く返ってくる印象です。
• 逆に良いコードに対してはあまり効果がないかもしれません。
• コード単体はレビューできますが、全体アーキテクチャに沿った大局的な指摘はまだできません。
• 本記事はコードレビューに絞った内容となっていますが、新規コードや既存コードの改修も実用的です。
• 2024年は間違いなくコード生成AIを活用できるエンジニアとそうでないエンジニアで生産性に大きな差が出るでしょう。

最後に

• CTOの倉さんを始め GitHub Copilot の導入に携わってくださった皆様に感謝です。
• 明日は @dhorio さんの記事となりますので引き続きよろしくお願いいたします。