「動いているコードは触るな」。
リファクタリングを提案したとき、こう返されて言葉に詰まる場面は珍しくありません。
言う側にも、小さな修正で本番を壊した記憶や、直した結果の責任を背負ってきた重みがあるはず。
正論で押し切れば角が立ち、引けば負債だけが積み上がるという板挟みです。
テックリードとしてこの一言にどう答えるか、迷ったことはありませんか？
「触るな」が守ろうとしているのは振る舞い
まず押さえておきたいのが、リファクタリングという言葉の定義。
Martin Fowler は、リファクタリングを「外から見た振る舞いを変えずに、内部の構造を理解しやすく変更しやすい形へ変えること」と定義しています。
進め方も、振る舞いを保つ小さな変換を一つずつ積み重ね、そのたびにシステムを動く状態に保つというもの。
つまり定義のうえでは、リファクタリングは「動いているものを動いたまま直す」作業なのです。
では、なぜ「触るな」と言われるのでしょうか。
相手が恐れているのは構造の変更そのものではなく、直したつもりで振る舞いまで変わってしまい、それに誰も気づけないことのはず。
反対の正体は「リファクタリング」ではなく「確かめようのない変更」と捉えると、答え方が見えてくる。
定義の原文は、Fowler のサイトRefactoringで読めます。
答え方①：直す前に「今の動き」を固定する
確かめようのない変更が怖いなら、先に確かめる手段を用意する、という順番で考えたいところ。
Fowler 自身も、リファクタリングはテストが通っている状態でだけ行うべきだと書いている。
悩ましいのは、「触るな」と言われるコードほど、たいていテストが薄いこと。
Michael Feathers は著書『レガシーコード改善ガイド』（原題 Working Effectively with Legacy Code）で、テストのないコードをレガシーコードと呼んでいます。
同書が勧めるのは、あるべき仕様を書くことではなく、今のコードが実際にどう動いているかをそのまま写し取るテスト（characterization test）から始める進め方です。
仮に今の動きにバグが含まれていても、まずはそのまま記録しておくのがポイントになる。
こうしておけば、「壊れていないことを何で確かめるのか」という問いに、テストの結果で答えられるようになります。
合意を取りに行く前に、安全網を先に張ってしまうのが、いちばん説得力のある答えなのです。
テストが通っている状態で直すという前提は、Fowler のOpportunistic Refactoringにも書かれています。
答え方②：小さく分けて、機能の変更と混ぜない
安全網があっても、一度に大きく変えれば不安は消えません。
ここで効くのが、Kent Beck の「まず変更を簡単にし、それから簡単な変更をする」という言葉。
Fowler はこれを準備のためのリファクタリング（preparatory refactoring）として紹介し、森をまっすぐ突っ切るより、いったん高速道路まで出たほうが早く着くという Jessica Kerr のたとえを添えています。
機能を足す前に、足しやすい形へ構造だけを整えておく、という順番です。
たとえの原文は、Fowler のAn example of preparatory refactoringで読めます。
この順番には、合意の取りやすさという副産物もついてくる。
構造を整える変更と振る舞いを変える変更を同じプルリクエストに混ぜると、レビューする側は「どこで何が変わったのか」を見分けられません。
逆に、リファクタリングだけのプルリクエストなら、テストの期待値を変えずに全部通っていることを示すだけで済みます。
小さく分けることは、レビューする人の不安を減らす手段でもあるわけですね。
Fowler はこの切り替えを、Kent Beck の「2つの帽子」というたとえで説明しています。
機能を足す帽子と、構造を直す帽子を同時にかぶらない、というシンプルな約束。
レビューの運用ルールそのものは、コードレビュー文化を扱った別の記事にまとめました。
答え方③：「いつ直すか」を日々の仕事に埋め込む
最後に残るのが、「そんな時間はない」という反対です。
Fowler は、リファクタリングを特別な期間に予定するものではなく、コードが散らかっているのを見つけたらその場で少しずつ片づける、日常の活動として捉えるよう勧めている。
合言葉は、「来たときよりも、コードを少しよい状態にして立ち去る」というキャンプ場のルール。
触る場所を直すついでに整えるだけなら、まとまった時間の承認は要りません。
一方で、同じ記事には気をつけたい点も書かれています。
一つは、直し始めると次々に問題が見つかり、元の作業に戻れなくなる深追い。
もう一つは、コードの持ち主を厳しく決めすぎる運用や長く生きるフィーチャーブランチのように、ついでの手直しをしにくくする開発の進め方です。
テックリードが手を入れられるのは、まさにこの環境側の二つなのです。
どこで止めるかをチームで決めておき、ブランチを短く保つ。
個人の勇気に頼らず、直しやすい仕組みのほうを先に用意することが、「触るな」を減らす近道になります。
まとまった返済の時間が必要なときの説明のしかたは、技術的負債の見える化を扱った記事で整理しました。
最後に
「動いているコードは触るな」への答えは、言い負かすための反論ではありませんでした。
今の動きをテストで固定し、小さく分け、日々の作業の中で直すという三つの手当て。
どれも、相手が抱えている「壊したらどうする」という不安に、正面から答える方法になっています。
私自身はまだテックリードを目指して学んでいる立場ですが、反対の声を「リスクの指摘」として受け取る姿勢は今日の仕事からでも試せそう。
まずは次に触るコードで、今の振る舞いを写すテストを一本書くところから始めてみます。
以上です。
コメントを残す