Codexでコードを整理する

コードが長くなって読みづらいとき、Codexに整理を頼めます。ただし、読みやすくする作業で計算結果や使い方まで変わると、別の確認が必要になります。

リファクタリングは、外から見た動作を保ちながら内部の書き方を整理することです。この記事では、対象を小さく決め、変更前後を比べる依頼方法を説明します。

機能追加と整理を分ける

「読みやすくして、値引き機能も付けて」と同時に頼むと、結果が変わった原因を追いにくくなります。まず現在の動作を整理し、機能追加は別の変更として扱うと確認しやすくなります。

たとえば、単価と個数を掛ける処理の変数名を分かりやすくするだけでも、小さな整理です。

変更前の例：

export function total(p, q) {
  return p * q;
}

変更後の例：

export function total(price, quantity) {
  return price * quantity;
}

関数名 total と引数の順番、返す値を保ち、内部で使う名前を変えています。この例では引数の名前を外部から文字列として調べるなどの特殊な使い方を想定していません。実際のコードでは呼び出し側も確認します。

total.mjsの合計計算を読みやすく整理してください。
先に呼び出し元と既存テストを確認してください。
関数名、引数の順番、戻り値、入力の扱いは変えないでください。
今回は変数名の改善に絞り、新機能や依存パッケージは追加しません。
変更前後に同じテストを実行し、差分と結果を説明してください。

「自由に最適化」よりも、今回改善したい読みづらさを示すと、変更の理由を確認できます。大きなファイルなら、最初は一つの関数や一つの責務へ絞ります。

各段階で確認してから、次の操作へ進みます。

図解Codexでコードを整理する：進める順番

具体的な依頼と、結果の確かめ方は本文にあります。

図の最初にある変更前の確認が大切です。すでに失敗しているテストを、今回の整理が原因だと誤解しないようにします。

行数が減っても、何をしているか分からなくなれば改善とは限りません。説明を読んで納得できない場合は、「この変更で何が読みやすくなるか、具体的に示してください」と聞けます。

テスト入門の合計計算なら、300×2、300×0、0×2を変更前後に実行します。これで確認できるのは、その入力に対する結果です。あらゆる入力で同じ動作を証明したことにはなりません。

既存テストがない場合は、まず代表的な入力と出力を記録します。複雑な処理では、現在の振る舞いを押さえるテストを用意してから整理へ進む方法があります。今回の変更と無関係な大規模テスト基盤まで、一度に導入する必要はありません。

無関係なファイル、依存関係、画面の見た目まで変わっていれば、なぜ必要かを確認します。目的に必要な部分を残し、不要な変更を今回の差分から外します。

戻すときは、もともとあった変更まで消さないようにします。差分の確認と別案を試すブランチの考え方が役立ちます。

「変数名を意味の分かる名前にした」「外部から呼ぶ関数の形は維持した」「指定のテストが変更前後で成功した」のように、変更理由と確認範囲を残します。

このページのコードは整理の考え方を示す小さな例です。自分のプロジェクトでは、参照元と変更箇所を探すところから始め、実際の利用箇所に合った確認を行ってください。

掲載した変更前後の関数をWindows・Node.js v24.14.1で実行し、同じ三つのテストが両方で成功することを確認しました。すべての入力やCodexの作業全体を検証したものではありません。