カーソルを使用したレガシーコードのリファクタリング (最初にテスト、二番目に勇気)
テストのない 600 行のモジュールがカーソルに達しました。本番環境を中断することなくリファクタリングしたワークフローは、AI よりもむしろシーケンスに重点を置いたものでした。
このモジュールは 600 行、10 年前から使用されており、耐荷重性があり、運用トラフィックのみでテストされました。 Cursor はうまくリファクタリングしましたが、AI はおそらくストーリーの 3 分の 1 でした。残りの 3 分の 2 は順序付け、つまりテスト、境界、エージェントの高速移動の拒否でした。
ステップ 1 は特性評価テストであり、Cursor はテストの作成を支援するのに非常に優れています。私はモジュールを読み取って、入力、出力、エッジケース、エラーパスなど、観察可能なすべての動作をリストするように依頼しました。次に、奇妙なものを含む現在の動作をアサートするテストを生成し、「特性評価: 正確さではなく、現在の動作をアサートします」と明示的にラベル付けします。これらのテストは、その後のすべてを可能にするセーフティネットです。
ステップ 2 は手術前の境界です。 Cursor に動作を変更せずに最初に継ぎ目で純粋な関数 (解析、計算、書式設定) を抽出させたところ、各抽出は緑色で検証されました。それから初めて、実際のリファクタリングが機能ごとに開始され、「パスごとに 1 つを変更し、テストを実行し、停止する」という最も重要な指示が出されます。大胆にリファクタリングするエージェントは、自信を持って書き直し、微妙に壊れます。その間を検証しながら小さなパスを実行することで、制御を維持できます。
誰も重要だとは思っていないステップです。適用する前に、Cursor に各変更を 1 文で説明させました。この説明では、テストでは把握できなかった 2 つのことを捉えています。それは、同時実行性のみを考慮した共有オブジェクトの変更、もう 1 つはテストのタイムゾーンでは安全で本番環境では安全ではなかった操作の並べ替えです。一文の理論的根拠を読むと、変化ごとに 10 秒かかり、網が見逃したものを捕まえることができます。
最終的な集計: モジュールは 300 行になり、新入社員が読むことができる構造、特性評価スイートによって動作が同一であることが検証され、生産インシデントはゼロになりました。 AIがタイピングをしてくれました。規律がリファクタリングを行いました。どちらも必要でした。そのうちの 1 つだけがオプションでした。
