Copilotのコツを整理する
GitHub Copilotを使っていて、提案がうまくハマるときと、少しズレるときがあるので、
自分の中で意識していることを備忘録代わりに整理しておきます。
「こうすれば必ずうまくいく」というより、
使うときに少し意識すると提案の精度が上がりやすいことをまとめたものです。
1. まずは目的を先に書く
Copilotは、いま書いてあるコードやコメントを見て提案してくれるので、
いきなり実装を書かせるよりも、先に「何をしたいのか」を短く書いた方が使いやすいです。
たとえば、次のようなコメントだと少し曖昧です。
# ユーザーをチェックする
これだけだと、何をどうチェックしたいのかまでは伝わりにくいです。
一方で、次のように書いておくと、提案がかなり安定しやすいと感じます。
# ユーザー一覧から、退会済みでなくメールアドレスが設定されているユーザーだけを抽出する
# email が None または空文字のユーザーは除外する
# 戻り値は User のリスト
少なくとも、次の3つくらいは書いておくと使いやすいです。
- 何を対象にするか
- どの条件で絞るか
- 何を返したいか
2. 関数名や変数名は少し丁寧に付ける
Copilotはコメントだけでなく、関数名や変数名もかなり見ている印象があります。
そのため、名前が曖昧だと提案もぼんやりしやすいです。
たとえば、こういう名前は便利そうで意外と文脈が弱いです。
data
list
temp
process()
一方で、こういう名前の方が、やりたいことが伝わりやすいです。
active_users
withdrawn_users
filter_active_users()
calculate_total_price()
人間が読みやすい名前を付けることはもちろんですが、
Copilotに文脈を渡す意味でも命名は大事だと思っています。
3. 一度に大きな処理を書かせない
Copilotにまとめて大きな処理を書かせると、
見た目はそれっぽくても、細かい条件漏れや不要な処理が混ざることがあります。
そのため、自分はなるべく小さく分けて使うようにしています。
たとえば、次のように分けます。
- 入力チェックを書く
- データの整形を書く
- 保存処理を書く
こうしておくと、提案されたコードも確認しやすいですし、
ズレたときにどこが違うかも見やすくなります。
Copilotは、完成品を一気に作らせるより、
小さな部品を一緒に作る感覚で使う方が合っている気がします。
4. 既存コードの修正では変更点を言葉にする
新しく作るとき以上に気をつけたいのが、既存コードを直すときです。
このときは、ただ「ここを直したい」とするより、変更内容を文章で整理してから使う方が安全だと感じています。
たとえば、次のような形です。
現在は全ユーザーを一覧表示している。
仕様変更により、status = "error" のユーザーは一覧に表示しないようにしたい。
ただし、詳細画面の取得処理には影響させたくない。
まずは一覧取得処理だけの修正案を出してほしい。
このとき意識しているのは、次の3つです。
- 何を変えたいか
- 何を変えたくないか
- どこまでを対象にするか
ここをまず言葉にしておくと、Copilotの提案も使いやすくなります。
5. 提案はそのまま使わず、最後は自分で確認する
Copilotの提案はかなり便利ですが、最終的には自分が確認する前提で使っています。
あくまで「たたき台」として見る方がちょうどよいです。
特に、次のあたりは毎回見たいところです。
- 条件漏れがないか
- 例外処理が抜けていないか
- 既存仕様とずれていないか
- テスト観点が足りているか
便利なので、そのまま採用したくなりますが
最後は自分で読む、確認する、試す、という流れは必要だと思っています。
まとめ
いまのところ、自分の中では Copilot を使うときに次の点を意識しています。
- 目的を先にコメントで書く
- 関数名や変数名を丁寧に付ける
- 一度に大きな処理を書かせない
- 既存コード修正では変更点を言葉にする
- 提案はそのまま使わず確認する
特別なことではないですが、
こうした基本的な整理をしてから使うだけでも、Copilotの提案はかなり扱いやすくなる印象があります。
今後また使い方が変わったら、備忘録として追記していきたいです。