長すぎる関数を小さな単位に分割する

なぜこう書くのか

あなたは他人が作成した{{言語}}のコードベースを長年保守してきた開発者です。振る舞いを変えない整理のみを行い、機能追加や好みに基づく書き換えは行いません。

以下の関数は長すぎて可読性が低いです。外部から見た振る舞い（同一入力に対する同一出力、例外発生の条件、保存・送信などの副作用）は一切変えずに、小さな単位へ分割してください。

{{遵守すべき条件}}は必ず守ってください。この条件と衝突する改善案が思い浮かんだ場合は、コードを書き換えるのではなく、なぜ変更できないのか理由のみを教えてください。

一度にすべてのコードを書き直さず、まずは分割計画のみを表形式で提示してください。列は「新しい関数名・担う役割・元のコードの該当箇所・引数と戻り値」とします。私が「進めてください」と返信したら、その時に最初の関数から1つずつコードを提示し、私が次の指示を出すまで待機してください。

自己チェック

計画を提示する前に、分割後も元の関数と結果が一致するか自身で照合してください。条件分岐が重複する箇所や値が変わる可能性のある点があれば、表の下に「注意点」として記載してください。

入力資料

コード: """ {{コード}} """

リファクタリングのプロンプトで最もよくある失敗は、「この関数を整理して」と頼んだ結果、一見綺麗に見える新しいコードが丸ごと出力され、貼り付けた後になって初めて挙動が変わっていることに気づくケースです。どこで狂ったのかを探すには、結局2つのコードを1行ずつ突き合わせる羽目になります。

役割を「他人が作成したコードベースを保守してきた開発者」と設定したのは、作業スタンスを固定するためです。他人のコードを長く触ってきた人は、勝手に構造を改変しません。タスクの段落で「外部から見た振る舞い」を入力と出力、例外、副作用と具体的に書き下したのも同じ理由です。単に「挙動を維持してください」とだけ指示すると、戻り値の型だけ合わせてメール送信の順序を勝手に変えてしまうことがあります。

制約は変数として受け取ります。チームごとに変更できない事情は異なり、関数名が1つ変わるだけで呼び出し元がすべて壊れてしまうためです。条件と衝突する場合はコードを変更せず理由だけを述べるよう指示することで、AIが制約を勝手に破って「より良いコード」を提示してくる事態を防ぎます。

まず計画を受け取り、「進めてください」と返答してからコードを書かせる設計が、このプロンプトの肝です。一度にすべて受け取ると確認箇所が多すぎて、AIを鵜呑みにしてそのまま貼り付けがちになります。このように段階を踏んで進めることで、関数ごとに検証でき、気に入らない命名や分割の境界線を計画段階で修正できます。

計画表に「引数と戻り値」の列を入れたのも意図的な仕掛けです。名前と役割だけを決めると、分割した関数同士がグローバル変数を受け渡し合う構造になりがちですが、何を受け取って何を返すかを事前に書かせることで、責務の境界線が計画段階で明確になります。

用語が分からなければAha AIで: role-prompting, output-format

悪い例との比較

よくある悪い例

この関数長すぎるからリファクタリングして

(コードを貼り付け)

まったく異なる形状のコードが一度に出力され、その中で条件分岐の1つが静かに反転していたりします。どんな条件を守るべきか指定していないため、新しいライブラリが勝手に導入されたり関数名が変わって呼び出し元が動かなくなったりします。何をなぜ変えたのかの説明もないためレビューが実質不可能になり、結局元のコードに戻すことになります。

バリエーション

分割する前に何をしている処理なのか把握したいとき

以下の{{言語}}関数が行っている処理を、上から順に番号を振って箇条書きでリストアップしてください。各行は「〜する」と簡潔に書き、条件分岐はどのような場合にどこへ分岐するのかを併記してください。リファクタリングの提案は含めないでください。

""" {{コード}} """

他人が書いた関数を引き継いだ際に最初に使用します。改善提案を禁止することで、コードの理解と修正のフェーズが混ざるのを防ぎます。

重複したコードだけを抽出したいとき

あなたは{{言語}}の開発者です。以下のコードから同じ処理を繰り返している部分のみを特定してください。繰り返しが3箇所以上あるもののみを対象とし、共通化することでかえって可読性が下がるものは除外してください。該当箇所ごとに「重複部分・出現回数・共通化後のコード」の順で提示し、{{遵守すべき条件}}は必ず守ってください。