効果的にリファクタリングする

これは、Dominik Dorfmeister 氏のブログ記事であるRefactor impactfullyを日本語訳してみたものです。

誤訳などあればIssueや PR を頂けると幸いです。

---

小さなリファクタリングは別として、責任ある開発者として、常に許可を求めることなく機能の要望と共にリファクタリングを行うべきですが、 大きいリファクタリングには必ず何かコストが生じます。 うまくパッケージにできていても、本当に必要なことなのか、また、時間とリソースをより上手く使えないのか、誰かしら疑問に感じるでしょう。

リファクタリングするのに適切なものを選ぶことがとても重要な理由は、ここにあります。ほとんどのアプリケーションは、変更可能な大量のコードが存在します。 整頓された技術スタックと綺麗なコードを好む筆者としては24時間365日リファクタリング以外のことができなくなります。技術的な面でも物事が整頓されているのは気分が良いものです。

レストランのキッチン

私はこの例えば好きなので、良い機会に使わせてください。

私たちの会社は、お客様に料理を提供したいレストランのようなものです。私たち開発者はキッチンで料理を作れるように働いています。機能をリリースすることは食事を調理することに似ています。 料理をする都度、キッチンは少しづつ汚れていきます。従って料理を続けるためには、時々キッチンを掃除することが必要です。全く掃除をしないと料理を続けるための清潔なフライパンや包丁などが全くない状態になってしまいます。

この掃除がリファクタリングであり、リリースしながら蓄えてきた技術的負債を返すことです。

しかしながら、レストランにお客様がいなければ整頓されたキッチンは無益です。そのため、毎日ただ掃除を行うだけ行うわけにはいきません - バランスをとる必要があります。

全てをリファクタリングすることはできないので、私のアドバイスは以下のとおりです。

キッチンの例で考えると、壊れた食器洗い機を交換するべきか輝きのある新品のプレートを買うべきか、どちらでしょうか？食器洗い機を交換する方がよりインパクトがあることは明らかでしょう。

実例

コードベースを見ていたら、データの取得にaxiosを使用していることが分かりました。 サポート対象の全てのブラウザにおいてビルトインのfetch APIがサポートされているのにそうする必要があるのでしょうか？

axiosに似たkyのようなfetchの小さなラッパーは3分の1程度小さいです。その上XMLHttpのリクエストを今後使用することはないでしょう。。。

よりモダンにする良い機会だと、私は心が躍りました。

リファクタリングしなかった理由

率直にいうと、どうでも良いことだったからです。サイズの改善は重要ではありません。3キロバイトと9キロバイトの比較の話です。一方が”速い”わけでも”よりメンテナブル”というわけでもありません。 axiosについて本当に何も問題を抱えていません。

このようなリファクタリングは非常に外見的なものとなり得ます。開発者が行いたいものだとしても、必要性のないものです。 ユーザー体験とメンテナビリティの両方によりインパクトのあるような、もっと取り掛かるべきことが少なくとも10個はありました。

これは罠です

また、少しリスクを伴います。APIレイヤーは全てのページで利用されているので、リファクタリングに大量のテストを必要とします。最悪の二重苦です。ほとんど良い影響をもたらさず、むしろリグレッションの大きなリスクを伴います。

リファクタリングするものを選択するとき、この罠に嵌まらないように気をつけましょう。修正しようとしていることが本当にユーザーや仲間の開発者たちにインパクトをもたらすものかどうかよく考えましょう。