たとえるなら
味は変えずに厨房を整理整頓することです。お客さんから見える料理（動作）は何も変わりませんが、道具の置き場が整えば、次の料理は速く正確に作れます。すぐには売上に見えなくても、続けている店ほど強くなります。
もう少しくわしく
リファクタリング（refactoring）は、プログラムの動作は一切変えずに、ソースコードの中身だけを整理して読みやすく直す作業です。わかりにくい名前を直す、重複した処理をひとつにまとめる、複雑になりすぎた部分を分割する——外から見える機能は何も変わらないのに、コードの質は確実に上がります。
なぜそんな作業が必要かというと、コードは機能追加や修正を重ねるうちに、少しずつ散らかっていくからです。締め切りに追われて書いた応急処置、当時は良かったが今では古くなった書き方。散らかったコードは読み解くのに時間がかかり、修正のたびに新しいバグを生みやすくなります。この「散らかりの蓄積」は技術的負債（借金）とも呼ばれます。
リファクタリングは、その借金を少しずつ返す活動です。新機能のような目に見える成果ではないため後回しにされがちですが、長く続くサービスほど、この地道な片付けが開発スピードを支えています。機能を直すついでに周辺を片付ける、という習慣を持つチームも多いです。
現場での使われ方
「この機能を触る前に、まずリファクタリングさせてください」
今のコードのままでは安全に修正できないので、先に整理する時間がほしい、という提案です。
「動作は変わってません。リファクタリングだけです」
この変更は機能追加でも不具合修正でもなく、コードの整理だけ、というレビュー時の説明です。
よくある質問
リファクタリングとバグ修正の違いは何ですか？
バグ修正は「間違った動作を正しい動作に変える」こと、リファクタリングは「動作は変えずに中身を整理する」ことです。動作が変わるかどうかがはっきりした境界線になります。