レガシーコードの塩漬けはうまいか？
作り直しにつきまとう二重運用
作り上げたシステムが度重なる改修を経てレガシーコード化したり、市場のニーズや技術トレンドの変化により既存のシステムでは対応が難しくなったとき、システムの作り直しが検討の俎上に上がります。
このときに見落としがちで、かついつまでも頭を悩ませるのが「既存のシステムをどうするか」です。
少なくとも、新しいシステムが形になるまでは既存システムの保守運用は必要ですし、新しいシステムはいきなり完成形にはならないので、たいてい新旧システムの二重運用が必要になります。
ストラングラーフィグパターンのようにうまいこと移行できるといいのですが、現実問題として二重運用に悩まされる現場は少なくありません。状況によっては旧システムがえんえん延命を続け、開発効率向上のためにシステムを刷新したのに旧システムの保守運用がのっかりつづけて開発を圧迫…なんてこともザラです。
使ってる人がいるから…
システムを移行する際、既存システムの機能全てをキャッチアップするのではなく、いくつかOmitして提供することを検討します。あまり使われていないもの、保守運用コストがバリューに見合わないものは積極的に閉じていきたいところですが、そうは問屋が卸しません。システムに機能として存在している以上、少数であっても使っている人がいるのが世の常です。この場合、「まあ使っている人がいるし、機能としては残しておくか…」という意思決定に至る場合が稀によくあります。
塩漬け
作り直すほどではないけれども、使っている人がいるから機能を残そうというときに選択肢として挙がってくるのが、「塩漬け」です。
機能開発の対象からは外し、本当に必要不可欠な最低限度の保守運用のみで機能を維持するという戦略です。
過去関わってきたレガシーコードのうちいくつかは「塩漬け」の戦略をとってきましたし、有効なケースもありました。
塩漬けが有効な場合
以下のような限定的な状況では、塩漬け戦略は有効です。
インターネットから遮断されていてセキュリティリスクがない
バグがあっても修正しないという顧客合意ができている
ハードウェアとの間に依存性があり、ハードウェアの販売・サポートが近々終了する
たとえばガラケー向けのサービスであれば、ガラケー停波まで待つことでそのサービスを利用する人がいなくなる状況が生まれます。なので塩漬けは有効な戦略です。
Webサービスはおわらない
ただ、Webサービスの場合、当然ながらいちばんめの「インターネットから遮断されて」が適用されないんですよね。
インターネットと接続した時点で、セキュリティイシューとは一生お付き合いすることになります。あなたがエンジニアなら「こいつは何を当たり前のことを言ってるんだ」と思うかも知れません。
でも、案外、「インターネットにつながってる時点でライブラリやらなんやらのアップデートはし続けなければいけない」という感覚を意思決定者はもってなかったりします。
だから、塩漬けのデメリットは把握しておこう
なので、レガシーコードをどう扱うか？という文脈で「塩漬け」が出てきたら、それがほんとうに塩漬けできる代物か、というのは丁寧に点検することをおすすめします。
塩漬け前提で進めていたら、実はガッツリメンテナンスが必要だった…なんてのは避けたいですからね。