リファクタリングは常に正義なのか

2022/2/19作成

リファクタリングといえば大抵は正義だと語られると思いますが、そうとも限らないというカウンターの意見をちょっと書きます。だからってリファクタリングが絶対悪であるとも思ってなくて、ケースバイケースってことです。

一つには、既存のコードに修正を加えるときにリファクタリングを一緒にするのって怖いよねってことですね。バグった時に、修正がバグったのか、リファクタリングがバグったのか切り分けが難しくなるし、そもそも修正量が多くなるからバグる可能性も高くなるし。既存の機能を書き換えてしまうような修正で、新規部分をきれいに書きましょうっていうのならいいんですが、それはリファクタリングとは言いませんよね。

こういう場合にバグらないように自動テストとかがあるわけですが、それとて完璧ではありませんし、そもそも機能修正が入ってるとテストコードも修正しないといけないので、そちらでもバグが入る可能性も出てくる。

では機能修正とリファクタリングは分けて行うかっていうと、これもちょっと難しい。これは今度は主に工数の問題ですね。リファクタリングの工数を十分に割けているチームならいいんですが、大抵の開発チームは機能開発に手一杯で、リファクタリングにまで時間を割く余裕はありません。手が空いたときにリファクタリングしようねといいつつ、何年も過ぎてしまっているというのはとてもよくある話でしょう。

規模によってはそもそもリファクタリングが可能なのかって話もあります。テストコードが一切無い100万行のレガシーコードがあったとして、これをリファクタリングするでしょうか。1人月で1万行がリファクタリングできたとして、100人月の工数を一切の利益を生み出さないリファクタリングに費やせますか。そりゃまリファクタリング出来れば、以後の開発工数を大幅に減らせますから、その削減工数次第なんですけどね。

銀行の勘定系システムとかはそんな感じらしいですよね。リファクタリングを一切諦めて、動いてるところは一切触るな。機能修正するときも、既存コードを修正してはいけなくて、コピペして新規コードを追加するという感じで。そうしてどんどん技術的負債が溜まっていくわけですが、これはもう人類には返済できるもんじゃないですよね。将来AIがもっと賢くなってくれたら、自動リファクタリング出来るようになるかもしれませんが。

というような事を考えていると、いっそ一切リファクタリングしないってのも一つの方法かもしれないなとも思うんです。ああ、もちろん新規に書き下ろすコードはきれいに書くのが前提ですよ。クソコードを新規にコミットしていいという免罪符の話をしてるわけではありません。そうして局所的にはきれいなコードを書き続けていても、何年も経つと当初の設計思想ではカバーしきれない拡張が繰り返されて、どうしたって熱海の温泉旅館状態になってしまうわけです。それを少しずつ修正してきれいにしていこうというのがリファクタリングだとしたら、いっそ新規に作り直したらいいじゃないかという考え方もありだと思うんです。

以前どこかで読んだ話ですが、式年遷宮をヒントに数年に一度システムを新規に作り直しているところがあるそうです。式年遷宮では一定の期間ごとに神社を建て直すことによって、建物が新しくなると共に建築技術の継承も行っているそうなんですね。システムでもそれって大事ですよね。古いシステムを継ぎ足しだけで作っていると、今のスタッフは新規にシステムを立ち上げる経験ができません。でも数年おきに作り直すのなら、そういう経験もできます。それまでの数年間の運用を振り返って、設計を見直すことも出来ますし、その数年の間に登場した新しい技術を取り入れることも出来ます。こうしてみると式年遷宮ってなかなかいい方法に思えますね。もちろん、どんなシステムでもこれが適用できるとは限りませんけどね。ある程度までの規模のシステムでしか通用しないでしょう。もしくは、巨大なモノリシックなシステムではなく、マイクロアーキテクチャにしておいて、個別のシステムごとに式年遷宮していくというのも方法ですかね。その場合システム間のインターフェイスの更新をどうするかって課題は残りますが。