小さなバグ修正のたびに大幅リファクタリングをするかって話、自分も悩んだことあります。正直に言うと、状況次第だなって結論に落ち着きました。

前の案件で、古いコードベースの軽微なバグ修正を任されたんですね。そのとき「この際だから構造を整理しちゃおう」と張り切ってリファクタリングに着手したんです。でも途中で気づいたのは、修正箇所と全然関係ない部分まで手を入れてしまってて、レビュー期間が予定の3倍になっちゃった。バグ修正という本来の目的が曖昧になってしまったんですよ。

その失敗から学んだのは、スコープを明確にすることの重要性です。今は「このバグ修正に最小限の変更で対応する」と決めたら、関連する小さな改善にとどめます。ただし、修正中に「ここはいずれ問題になりそうだな」と感じたら、それは別チケットとして記録しておく。

興味深いのは、チーム全体でレガシーコードに向き合うペースが決まってるかどうかで、個々の対応も変わってくるってことです。継続的にリファクタリングする文化があれば、小さな修正も全体計画の一部になり得るし、そうでなければ修正は修正、改善は改善で分けた方がスッキリします。