リファクタリングをいつ、どのようにやるか

コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？

リファクタリングには方針が必要

リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。

では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで、どの辺は変更しなさそうか」ということに考えを巡らせながら、今日もコードを書いていくわけです。

例: ログイン機能を実装する

具体的な例を考えてみよう（「養殖の問題」になるのは許してほしい）。

エンジニア向けのサービスを作ろうとしている。ログイン機能が必要だ。email/passwordログインがあればいいという話で進んでいる。さて、どうやって実装してこうか。

ここで、経験豊かなお前らなら、どうせ他の認証にも対応したいってなりそうだなって思うだろう。Twitter, Facebook, GitHub, Google, …。最初は不要かもしれないが近々欲しくなりそうな機能、これが「どの辺に変更が入りそう」ってやつだ。

たとえばemailログインで、メールじゃなくて他の文字列になることもある。たとえばサービス内部のID（Twitterはある）や登録した電話番号（Facebookは確かこれ）など。やる？これ？やらなくてもいいんじゃね？これが「どの辺は変更しなさそうか」っていうことになる。

大抵の場合、全方位に拡張性を担保することは経済的ではない。なので、リファクタリングにはプロダクトの方針が必要になる。では次に、具体的にどういうタイミングで判断できそうか、少し紹介しよう。

次の機能を足す直前

上の例で言うと、emailログインをサポートして、サービスをローンチして、その後に「GitHub認証がやっぱり必要だ」みたいになったときが、リファクタリングの機運だ。

ローンチ当初では、GitHub認証の需要はよくわからない。なので、そこを実装すべきかよくわからない。つまり「変更しそうかしなさそうか不明である」というのが本当の初期状態だ。いや、「話題になった」という時点で、変更しそうな予感はするものだけど…、まあいいや。

で、そのとき、既存機能に手を加えずに認証機構を足すことができてたとしたら準備しすぎだし（ライブラリとかでついでにもうサポートされてるならまあ良いんだけど、養殖の問題設定なのでその辺は適当に流していただきたい）、もしくは「完全に横に生やす」ってやつで冗長さを以て既存機能を触らないようにするのも未来がない。

既存のemailログイン機能を少し変えつつ、GitHub認証に対応していこう。ちょうどいい感じのリファクタリングを見つけることができる。

あえて機能を少なく実装する

では、応用編だ。

別の世界線では、なんとローンチ当初からemailログインの他にGitHub, Twitter認証の需要があり、サポートしようという方針がわかっていた。すばらしい！マーケティングの勝利だ！

残念ながら、現実のマーケターはそこまで優秀ではない。ローンチの3ヶ月後に「やっぱりGoogleも必要だ…」ということに気づくだろう。ほらやっぱりそうなると思った！

こういう「ありそうな機能追加」に対応するために、あえて、当初に「Twitter認証に対応しない」という実装をするといい。email, GitHub認証ができたあとに、Twitter認証の機能を実装していく。そこでOpen-Closed原則が保たれているか、リファクタリングの余地がないかを確認しつつ変更していくといい。

段階的に対応できるようにすることで、方針転換にも対応しやすくなる。ローンチの1週間前に「やっぱりTwitter認証は後回しでいいから、他の機能を充実させたい」となっても、いちいち喧嘩する必要はない。何度でも言うが、マーケターは未来を予知できるほど優秀ではない。一緒にがんばろう。

まとめ

• 何にでも備えたものは、何者にもならない
• 既存機能を横展開する前に、一度立ち止まって考えよう
• リファクタリングは老人たちの経験が役立つ世界だから、そのうちAIが解決するかもね