個人的には三つの基準があるという話。
- そのソフトウェアが十分に古く、十分長い間保守されていないか
- そのソフトウェアを触れる人間が組織内に少なく、増やす手だても困難であるか
- そのソフトウェアで実現できることが、他の新しいソフトウェアでより容易に実現できるかどうか
1. についてはそうだろう、という感じだと思う。というかリプレイスの前提になると思う。バージョンが古いソフトウェアを使い続けると、脆弱性も出てくるし、一般的には開発の速度も低下する。
ただ、ここで重要なのは、2.や3.との兼ね合いかなと思っている。
例えば2.が1.より優先される場面というのもあるだろう。Hoge言語で作ったミドルウェアの保守について以下のような状況にあるとする。
- 開発者が退職してしまった
- Hoge言語に関するドキュメントが全然なくて学習が困難
という感じであればリプレースは検討に入れていいかもしれない。
しかし、ここで3.の観点も大事で、例えば古いからといってcronやlogrotateやらを別のミドルウェアにリプレースしようとする人はいないと思う。こういう場合は古い、ではなく枯れている、と呼ぶ。
とはいえ、最近のLinuxミドルウェアなんかを見ていると、枯れ果てたソフトウェアを平気でリプレースしかけてくる印象があり（典型的にはchronyやsystemdの登場）、もっと頭を柔らかくしないといけなそう。やっぱり「新しいソフトウェアでより容易に実現できる」のが大事なんだろう。
話戻って、ミドルウェアと違って言語に関しては、「変更し続ける」という観点が出てくるので、「枯れている」ことのメリットが少し小さくなる。例えばHoge言語に固有の優れた点があるのであれば（Erlangとかが連想されそう）頑張ってHoge言語を学習する方向でもいいと思うし、Hoge言語自体が古ければバージョンの高いHogeで書いても違うFuga言語で書いても書き直しという点では同じだろうし、そもそもそのミドルウェアを捨ててしまうのもアリかもしれない。
ここで感心しないパターンというのもあって、特に「自分がよく知らないからリプレースする」というのはあまりいい結果を生まない気がする。リプレイスはなんだかんだ多大なコストがかかるので、無知より、まだ好悪とか情熱とかでドライブされている方がうまくいくんじゃないだろうか...と思っている。
というのも、既存の技術情報について調べない、ということは、既存の 仕様 についてもよく調べずに思い込みで変更をぶっこんで意図しないトラブルを起こしがちな技術者の傾向の表出だと思われる。リプレースなので、トラブルは起こるだろうけれど、そういうものはコントロール可能な状態で起こさないといけない。
リプレースは大変だし、正解もないものなので、まずは冷静さが欲しいと思う。多分、0番目の基準が実はあって、「既存のシステムに対してリスペクトを持っている」という項目が必要なんではないか。
なお、やるな、という意味ではない。こういうことを言っておいてなんだけど、諸々コントロール可能なら積極的にやるべきと考える。
参考記事
- 何か新しいものを1つ入れるときは既存の何かを2つ以上減らせること
- ボトルネック以外触らない
至言。とはいえぼくは情熱とかその辺も許容するけど...。
どこぞでポエんだけど、せっかくなので書いてみる（たまには作った自慢じゃなくてウダウダとした考えのdumpもいいじゃない）。
