この記事の内容
  1. 変更しない挙動を列挙する
  2. 調査だけを先に頼む
  3. 一つの変更で一つの目的にする
  4. テストは人が期待値を確認する
  5. 例:共通関数へ移す順序
  6. ツールは採用しやすさで選ぶ

変更しない挙動を列挙する

例えば料金計算の重複を整理するなら、入力、丸め方、割引の適用順、表示する通貨を先に確認します。現在のコードだけでなく、仕様書や担当者が確認した例を根拠にしてください。現行コードに不具合がある場合も、今回直すのか維持するのかを決め、整理と仕様変更が混ざらないようにします。

調査だけを先に頼む

関数の呼び出し元、状態の変更、外部へのアクセスを説明してもらいます。どの処理が共通で、どこに例外があるかを確認してから、新しい共通関数を作るかを判断します。名前が似ている二つの処理でも、返す値やエラー時の動作が違うなら、安易に一つへまとめない方が維持しやすいことがあります。

一つの変更で一つの目的にする

変数名の変更、共通処理の抽出、ライブラリの置き換えを同時に行うと、失敗した原因を探しにくくなります。まず一つの呼び出し元で抽出結果を確認し、次に他の呼び出し元へ適用します。各段階で差分と確認結果を保存すると、想定外の変化が出た地点へ戻れます。

テストは人が期待値を確認する

生成されたテストが、新しい実装の結果をそのまま正解にしていないかを読みます。正常値に加えて、空入力、上限、無効な値、既存の例外を含めます。UIの変更なら、画面を開いたときの状態や操作後の保存も確かめます。テストが多いことより、守るべき条件が実際に検証されていることが重要です。

例:共通関数へ移す順序

同じ計算が三つの画面にある場合、まず一つの画面だけを共通関数へ置き換えます。事前に用意した入力例で結果を確かめ、差分がその画面に限定されていることを確認してから、残りへ適用します。三画面をまとめて変更するより、どの段階で挙動が変わったかを追いやすく、採用する範囲も選びやすくなります。

ツールは採用しやすさで選ぶ

Claude Code、Aider、Cursorなどを試すときは、同じ小さな整理を課題にします。採用した差分を説明できるか、不要な変更を取り除けるか、別の担当者が続きを修正できるかで判断します。全面的な書き換えを短時間で生成したことより、既存コードを壊さず少しずつ改善できることを重視しましょう。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について