リファクタリングといえば大抵は正義だと語られると思いますが、そうとも限らないというカウンターの意見をちょっと書きます。だからってリファクタリングが絶対悪であるとも思ってなくて、ケースバイケースってことです。
一つには、既存のコードに修正を加えるときにリファクタリングを一緒にするのって怖いよねってことですね。バグった時に、修正がバグったのか、リファクタリングがバグったのか切り分けが難しくなるし、そもそも修正量が多くなるからバグる可能性も高くなるし。既存の機能を書き換えてしまうような修正で、新規部分をきれいに書きましょうっていうのならいいんですが、それはリファクタリングとは言いませんよね。
こういう場合にバグらないように自動テストとかがあるわけですが、それとて完璧ではありませんし、そもそも機能修正が入ってるとテストコードも修正しないといけないので、そちらでもバグが入る可能性も出てくる。
では機能修正とリファクタリングは分けて行うかっていうと、これもちょっと難しい。これは今度は主に工数の問題ですね。リファクタリングの工数を十分に割けているチームならいいんですが、大抵の開発チームは機能開発に手一杯で、リファクタリングにまで時間を割く余裕はありません。手が空いたときにリファクタリングしようねといいつつ、何年も過ぎてしまっているというのはとてもよくある話でしょう。
規模によってはそもそもリファクタリングが可能なのかって話もあります。テストコードが一切無い100万行のレガシーコードがあったとして、これをリファクタリングするでしょうか。1人月で1万行がリファクタリングできたとして、100人月の工数を一切の利益を生み出さないリファクタリングに費やせますか。そりゃまリファクタリング出来れば、以後の開発工数を大幅に減らせますから、その削減工数次第なんですけどね。
銀行の勘定系システムとかはそんな感じらしいですよね。リファクタリングを一切諦めて、動いてるところは一切触るな。機能修正するときも、既存コードを修正してはいけなくて、コピペして新規コードを追加するという感じで。そうしてどんどん技術的負債が溜まっていくわけですが、これはもう人類には返済できるもんじゃないですよね。将来AIがもっと賢くなってくれたら、自動リファクタリング出来るようになるかもしれませんが。
というような事を考えていると、いっそ一切リファクタリングしないってのも一つの方法かもしれないなとも思うんです。ああ、もちろん新規に書き下ろすコードはきれいに書くのが前提ですよ。クソコードを新規にコミットしていいという免罪符の話をしてるわけではありません。そうして局所的にはきれいなコードを書き続けていても、何年も経つと当初の設計思想ではカバーしきれない拡張が繰り返されて、どうしたって熱海の温泉旅館状態になってしまうわけです。それを少しずつ修正してきれいにしていこうというのがリファクタリングだとしたら、いっそ新規に作り直したらいいじゃないかという考え方もありだと思うんです。
以前どこかで読んだ話ですが、式年遷宮をヒントに数年に一度システムを新規に作り直しているところがあるそうです。式年遷宮では一定の期間ごとに神社を建て直すことによって、建物が新しくなると共に建築技術の継承も行っているそうなんですね。システムでもそれって大事ですよね。古いシステムを継ぎ足しだけで作っていると、今のスタッフは新規にシステムを立ち上げる経験ができません。でも数年おきに作り直すのなら、そういう経験もできます。それまでの数年間の運用を振り返って、設計を見直すことも出来ますし、その数年の間に登場した新しい技術を取り入れることも出来ます。こうしてみると式年遷宮ってなかなかいい方法に思えますね。もちろん、どんなシステムでもこれが適用できるとは限りませんけどね。ある程度までの規模のシステムでしか通用しないでしょう。もしくは、巨大なモノリシックなシステムではなく、マイクロアーキテクチャにしておいて、個別のシステムごとに式年遷宮していくというのも方法ですかね。その場合システム間のインターフェイスの更新をどうするかって課題は残りますが。
(2023/3/24追記)
ネットワークセンターを大掃除してみたら… 30％の節電に！ 眠っていた設備撤去の裏側
ソフトウェアではなくてネットワーク機器の話ですが、やってることは大規模リファクタリングと呼べるかと思います。
30%の節電というのは有意なコスト削減効果があったわけですが、それに費やされた工数が6人で2年!かけた工数に見合ったメリットであったかどうかは中の人でないとわかりませんが、微妙な気はしますねぇ。30年物のデータセンターという事は多分移転や建て替えの話も出ていると思いますので、その時まで放置しようって判断も十分ありだと思います。移設の時に新規に構築し直せばその時にスッキリするだろうと。要するにビッグリライトですね。
大規模リファクタリングかビッグリライトのどっちが正しいかは一概に言えないので状況によって判断でしょうが、一つ言えるのは「手が空いたら少しずつリファクタリング」ってのは多分幻想です。実際には手が空くことなんてないし、空いたとしてもそんな片手間に進めるリファクタリングでは技術的負債の積みあがっていく速度に対して全く追い付かない。人をアサインして工数としてリファクタリングを案件化しないと進まないんだろうと思います。それをこのソフトバンクのように専門チームを作ってしまうのか、それとも週に1日はリファクタリング専念デーにしましょうなのか、交代でリファクタリング当番を決めて今週は君はリファクタリングしてねなのかは好きにすればいいのですが。チームの目標として「手が空いたときにリファクタリングしましょう」と掲げただけでは進まないし、それで期末になってリファクタリングが進んでなかったとしても、それはメンバーの責任ではなくて、リファクタリングにリソースを割かなかったリーダーの責任だと思うんです。