リファクタリングでシステムを安定化！日頃の取り組みや工夫を教えてください by カオナビカレンダー、4日目の記事になります。
今日あいていたので急遽寄稿させていただきます。
業務での開発におけるリファクタリングの基本について書こうと思います。
リファクタリングとは
一応さらっと。
ソフトウェア開発における「リファクタリング」とは、外からのふるまいを変えずに、内部構造を変更（通常は改善）することを意味します。
上記カレンダーに記載のあるとおり、「可読性・変更容易性の向上、複雑度軽減、技術的負債解消、など」をさします。
注意しておきたいのは、 何を「リファクタリング」と呼ぶかは個人差／チーム差がある ということです。
というのも、厳密にいえば、外から見たふるまいを全く変えない変更というものは滅多にないからです。
配列をハッシュリストに変えれば処理速度に影響が出ます。
jsのバンドルサイズが変わればページのローディング時間に影響が出ます。
それを「ふるまいが変わっていない」と呼べるかどうかは、結局のところ個人の認知能力によります。
本記事では、おおむね 「ふるまいの変更ではなく、内部構造の変更を目的として行う改修」 くらいの位置づけでリファクタリングという言葉を使います。
リファクタリングの王道
まずはリファクタリングを実施する際におさえるべきポイントです。
まずテストを書く
リファクタリングの前後で挙動が変わっていないことを担保するため、まずはリファクタリング前の動作を検証するためのテストコードを書きましょう。
どの粒度のテスト（ユニットテスト／API テスト／E2Eテスト／スナップショット比較テスト）を書くかは、リファクタリングの深さによりケースバイケースだと思います。
「ここが変わっていなければ大丈夫なはず」というポイントを保証するためのテストを書きましょう。
機能の変更とリファクタリングはコミットを分ける
リファクタリングをする場合は、リファクタリングのみのコミットを残すようにし、他の機能追加やバグ修正を同じコミットに混ぜないようにしましょう。
コードレビューがしやすくなるだけでなく、後から何か問題が生じた場合に、リファクタリングのミスによるものかどうかの切り分けがしやすくなります。
テスト済みのコードをリファクタリングしない
リファクタリングあるあるとして、コードに手を入れる本人は 「この修正で問題が起きるはずはない」という予測を過信しがち です。
おおかたテストも終わり、リリースの直前になってから、どうしてもここの作りを直したいという衝動に駆られることもありますが、テスト済みのコードに対しては（再テストの工数を取れる場合でない限り）リファクタリングをしない、というルールを厳守すべきです。
リファクタリングによってバグが埋め込まれることは十分起こりうるということ、そうなったときは100%自分が悪く、誰も庇ってくれないということを肝に銘じましょう。
その他Tips
実務の経験から、個人的に気にしたほうが良いと思うポイントを共有しておきます。
広範囲に手をつける前にコードレビューを依頼する
リファクタリングをする際は、コードの広範囲に手を入れることになる場合が多いでしょう。
全部終わってからコードレビューで「作りをこうしてしまうと問題がある」「こうやるよりこうしたほうがいい」という指摘を受けると、手戻りが大きく、無駄な作業が多く生じてしまいます。
リファクタリングに限らずですが、広範囲に手を入れる場合は、まず方針を決めた時点でチームメンバーにレビューを依頼し、認識をあわせておくのがベターです。
作業で競合が生じないことを確認しておく
リファクタリングで広範囲にコードの改修を行う場合、その影響範囲内で別の機能追加などを行おうとしているメンバーがいないことを十分に確認しておくべきです。
たとえ運用ルールとして、競合は後からプルリクエストを出した人が解消するものと定めていたとしても、自分が実装とテストを終えた箇所に対して、大きく作りが変わったので合わせてくださいと言われると精神的につらいものがあります。
あらかじめ、この範囲でリファクタリングをやりますので、影響しそうな箇所の改修は避けてくださいと伝えておくのをチーム仲のためにもおすすめします。
リファクタリングに時間を使う承諾を得る
リファクタリングというのはエンジニア以外の人からの理解を得にくい作業のひとつです。
ユーザーから目に見える変更ではないと言われると、「本当にそれやる必要あるの？」「自己満足じゃないの？」という印象を受けられがちです。
ソフトウェアを運用・保守していく上で必要不可欠な作業であるということを理解してもらうため、日ごろから開発チーム外との意思疎通、もっというと開発目線での啓蒙活動が必要です。
また、局所的な改修だと思ったら、いざやろうとしたときに根本的なリファクタリングが必要なことに気づく、というケースも多々あります。
その際は、同じ開発チーム内であっても、あらかじめ「これを直そうと思ったら先にリファクタリングが必要で、それには○時間くらい必要そうだ」という情報を共有しておかないと、簡単な改修のはずなのに、なんでそんなに時間がかかってるんだ？と思われてしまうので注意が必要です。
他人のコードを直すときには根拠を明確にする
自分の書いたコードに対して、他の人から「リファクタリングしました」とだけ言われて書き直されていると気分のいいものではありません。
他の人が書いたコードをリファクタリングする場合には特に、なぜ今の作りだとだめで、なぜこう直すのか、というのを説明し、理解を得る努力をすべきです。
同じような問題のあるコードを再生産させないという意味でも必要な労力になります。
以上
用法・用量を守ってハッピー・リファクタリングを！