GitHub Copilot パターン&エクササイズ
開発用LLMを使うTipsとして役に立つ事が多かったので見る。 General
関数名、引数が明確だと関数の内容が提案される事例
コメントからコードを生成
codeのコメントによって、関数全体を作ってくれる事例
思考
事例だと、以下の流れ
1. 関数、引数、返り値についてコメント
関数は名前。複雑なら説明もいる
引数は型
返り値は型。複雑なら説明もいる
2. 自動生成
実際やるなら、以下かな。
1. 関数、引数、返り値になどの、文章によるコメント。
2. 自動生成されるので確認/調整
3. コメントをJSDoc風に書き換えてもらう(コードからコメントの自動生成)
TSならいらないけど。
コードからコメントの自動生成
難しい関数に説明付けてもらう
感想
自分が書いた複雑な関数の改善や誰かが書いた理解していないcodeに付与すること多いな。
自身の理解を助けてもらって、改善アクションに繋げることも多い。
GitHub CopilotとのクイックQ&A
感想:
Q&A式は偶にやるな。
chat式で行うまでは無い事に使う印象
Rolesの設定はしたことなかったなぁ。やるならチャット式でやるかな？
正規表現
感想
入力&出力からから処理を作ってもらう考えは基本
動作確認のために、テストーケース再考してもらうのもいいね。
言語翻訳
感想: Rubyの処理をJS側に移動させる時とかやる。
タイプヒンティング
構造化データからのオブジェクト生成
感想
具体的なデータを渡して考えてもらうのはよくやるし便利
以外と専用の処理作るのダルかったりするんだよね。
コードからドキュメントへ
感想:
これいいな
要件ドキュメントをmarkdownで記述するより、構想例のcodeサンプルで書いたほうが書きやすく、イメージ掴みやすい事ありそう。
Client Side Tips
Copilot スニペットハンドリング
コンテキストとして利用されるcodeは、エディタで開いているファイル全てを見るわけでもない。
メインファイルとその隣接するタブファイルのみだったりする。
なので不要なファイルは閉じておいたほうがよい。
GitHub Copilot ショートカット
感想
全然使いこなせていない。効率化したくなったら学ぼうかな。
定義に移動
感想
大事！！！
特にTSの型や利用しているライブラリのcodeなどを追って見て、利用したい時に必須。
LLM無し時代も大事なアクションだったけど、LLMありになって自分が頑張って読み解く手間が減ったのが良い
便利なファイルのピン留め
感想
全然つかったことなかったな。
ある開発時にLLMが常に利用したいcodeはあるだろうから、利用すると便利かも。
Design Patterns
AIが読み取り可能な命名規則
注意点としては、間違った言葉の使い方をするとLLMに誤解される可能性があること。
一貫性のあるコーディングスタイル
tips
お手本のcodeが統一されていて、真似されやすい
仮に違った記法でも、Linterなどで簡単に調整できる。
Linterの設定ダルいけど重要度上がったなぁ
ハイレベルアーキテクチャを先に
プログラムのハイレベルなアーキテクチャを先に設計し、コードの各部分の機能と目的についてコメントしていくことで、LLMも文脈を理解して、提案しやすい。
初期に設計を自然言語で提案すると各詳細の実装がうまく提案されやすい。
小さなまとまりで作業する
小さなコードの断片をより少ないコンテキストで扱うと出力が向上する。
感想
人間でも同じ。
小さくタスクを分けて上げるのは、開発者がやって行くと良い。
それか、開発タスクを分ける行為は別の得意なLLMとやって、網羅させるとか。
コンテキストレス・アーキテクチャ
システム内のより小さく、明確に定義されたコンテキストにコーディングを限定するデザインパターンです。複雑なプログラムを疎結合で独立したコンポーネントに分割することで、このアーキテクチャは保守性、拡張性、柔軟性を向上させます。
同意。
Global Stateとかcomponent単位から飛び出す作り方は大変そう。
微細な OSS 依存関係の排除
感想
外部ライブラリの依存増やすと、LLMが学習大変なのはそう。
codeの記述がLLMで楽になるんだったら、codebase内で持つのもありだよね
ライブラリ保守工数かかるほうが効率悪い。
Collaboration
AIフレンドリーなドキュメンテーション
インフラストラクチャ定義やデータベーステーブル定義やテスト仕様などは、独自的な書き方よりも、テキストベースのドキュメントの方が学習しやすい事がある。
例: エクセルファイルを取り込めないけど、テキストベースのファイルであれば学習出来る。
プロンプトとコード生成プロセスのコーチング
生成プロセスへのコーチングは、開発者が潜在的な問題を認識し、効率的かつ正確なコードを作成できるようにするために不可欠です。
感想
Testing
ユニットテストの作成
ユニットテストの作成は、チャレンジングで時間のかかる作業です。GitHub Copilotを使用すると、このプロセスがより効率的に
感想
LLMの作った、codeの動作確認を目じゃなくて、パッケージングされた実際の利用で、何度も検証できるのがいいよね。
テストコード生成の方法を指定する
テストフレームワークや生成するケースの数などの具体的な詳細を提供する~とより正確で包括的な結果を得ることができます。
同意。
少なくとも10種類の有効な/無効な入力の組み合わせ
とかはいいね。無効な例を考えるのちょっと面倒だったりするので。
失敗ケースを最初に書く
思いつくなら失敗するテストケースの情報は記述してあげたい。
自然言語でテストケースを最初に記述する
↑と同じ。
必要な部分だけをテストする
普段の開発と変わらない。
Refactoring
リファクタリング前にテストコードを書く
イメージ
1. 動いているcode用意
2. テストケースを用意し、動くことを保証。
3. リファクタリングしてもらって、テストケースの動作保証する
計算ロジックを独立させる
普通のこと。
関数で切り分けたりして考えたほうが、人もAIも考えやすい。
オープン・クエスチョンで尋ねる
必ずしも何が正しく、何が間違っているかについてではなく、基本概念と潜在的な改善を理解することが重要です。GitHub Copilotでオープン・クエスチョンを利用することで、開発者は GitHub Copilot の助けを借りてより熟慮した方法でコードの改善に取り組むことができます。
分かる。ここは自分で提案するより、意見もらって、それを下に方針選択する方が、よりよいcode書ける。