GitHub Copilotの活用事例から用途を検討してみる
用途
- テスト(振る舞い)を記述しておき、コード実装をGitHub Copilotから提案を受けながら埋めていく
- 経験の浅いプログラミング言語のキャッチアップに利用する
- コード実装のペアプロ役として利用する
テスト定義とコード実装の役割を分担する
まずはテストを書いておき、テストを満たすようなコード実装を用意する。
実装部分はリファクタリング可能なので、テストを満たしていれば十分だと考える。
ただし、「テストを満たせば良いのでGitHub Copilotを利用して実装部分を用意ください」と言われても、複雑な振る舞いの場合は難しいため、振る舞いを構成する実装のI/Fを予め設計しておくことになりそう。
これには、GitHub Copilotを利用せずとも
- テストを用意する(振る舞いを定義する)ことができる人がいる
- テストを満たすような実装を単純な実装のコンポーネントに分解して設計可能な人がいる
という前提を頭に浮かべています。
何が嬉しいのか。
例えば、採用の場面でこれまでは開発力の面で採用を見送っていたような人たちが候補として入ってくる。
予め定義された単純な実装のI/FをGitHub Copilotを利用してなんとか実装できる人がいれば良くなり、コード実装担当者に求められる開発力のハードルが下がるため。
しかし、この建て付けだと、
- 設計と実装が分離されてしまって設計と実装間のフィードバックループの有無が気になる
- 実装フェイズを任せるための前提準備として設計フェイズの負担が大きくなりそうなのが気になる
ので、開発体制、開発フロー、開発文化などと合わせて検討したい。
慣れていないプログラミング言語のキャッチアップ
経験の浅いプログラミング言語の理解を深める際に役に立ちそう。
いろいろと書き方を提案してくれるため。
提案される書き方を見て、知らない要素を拾ってググって、あるいはChatGPTで尋ねて理解を深めるということができそう。
コード実装のペアプロ役
自分が熟知したコードベースで、自ら構成を設計して、テスト(振る舞い)を記述して、コード実装する際には不要かもしれません。
自分で実装した方が速そうという意味で。
一方で、実装方法がよく分からない場合に、試行錯誤してフィードバックを得ながら実装を進めていくような場合にはペアプロ役として役に立ちそうです。
- Q&A形式で利用することで、コード実装しながら疑問に対する回答が得られる
- コードを提案してくれる
この2点が役に立ちそうという感じです。
活用事例
「GitHub Copilot 活用事例」でググってこの辺を見てました。
- https://recruit.gmo.jp/engineer/jisedai/blog/how-to-hack-github-copilot/
- https://tech.macloud.jp/entry/2023/03/31/125606
- https://speakerdeck.com/tamago3keran/2023-04-14
- https://zenn.dev/search?q=github%2520copilot
- https://qiita.com/search?q=github+copilot
- https://techblog.gaudiy.com/entry/2023/04/20/162647
- https://goodpatch-tech.hatenablog.com/entry/2023/04/04/110847
- https://tech.cm-group.co.jp/posts/github-copilot
- https://techblog.olta.co.jp/entry/2023/04/14/192601
- https://tech.yappli.io/entry/make-apps-with-ai
まとめ
GitHub Copilotの活用方法に頭を回してみました。
開発活動の
- どのレイヤーで
- どのような課題を
解決するために活用するのかを意識して検討してみたいです。
他にも、いろんな観点で導入を検討してみたいと思いました。
- 新規開発/運用保守
- 自社開発/受託開発
- 複雑な振る舞い/単純な振る舞い
- リファクタリング/リアーキテクチャ
まだ深掘りできていないので、随時更新するかもです。
Discussion