だいぶ昔の話。とある製品に新機能を入れるプロジェクトを手伝うことになった。私の担当はごちゃごちゃした入力データをパーズする部分に新しい処理を入れることで、このパーザは別のチームが所有していた。
さっそく、件のパーザのコードを見てみると、これがやたらと複雑で、メモリ管理は無駄にややこしくみえるし、歴史的に蓄積されたハックが溜まっていて、とても触りたくないような代物だった。古いコードベースゆえ、クラス名や変数名などから古くさい感じがぷんぷんと漂っていた。
これいじるのやだなあと思っていると、サブディレクトリに、新しいバージョンと思われるコードが見つかった。作者に問い合わせると、古いパーザは別の人が書いたもので、汚くてメンテ不可能だから、新しいものを書き始めたのだという。
やっぱそうだよねえ、と意気投合して、新しいパーザを読んでみると、古い方とは比べ物にならないほどきれいに書かれていた。コードは整然としていて、APIもわかりやすく、テストも充実していた。これを書いたのはただ者ではない、と思わせる代物であった。
そこで、新しいパーザを使おうと思ったが、製品ではまだ古い方のパーザが使われていて、これから新しいパーザに置き換える作業を行うのだという。少し心配になったが、新しいパーザの作者は「すぐ置き換わるから大丈夫」と太鼓判を押してくれた。
あれだけのものを書いたエンジニアがそういうのだから大丈夫だろうと思い、新しい方のパーザに、私の担当する処理を入れることにした。この作業はスムーズに進み、ほどなくして私のコードは新しいパーザの一部となった。
さっそく、もう私の担当分は終わりましたよ、とチームのテックリードに伝えると、古い方のパーザにも同じ処理をいれないとダメだと言う。古いパーザはすぐ使われなくなるから、そんなことやる必要ないですよ、と言い返したが、テックリードは新しいパーザへの移行プロジェクトに依存するのはリスキーだから古いパーザも直そう、と言い張った。
テックリードはできるやつだし、言ってたとおりにするかと思い、しぶしぶと古いパーザの方にも同じような処理を追加することにした。新しいパーザでは、1,2日で終わった作業が、古いコードでは何日もかかり、しかも、その過程で、既存のバグをいくつも見つけて、それらを直す作業にも時間をとられた。そうはいっても2,3週間程度で作業は完了して、私が追加した処理はそのまま製品に組み込まれることになった。
一方で、「すぐ置き換わるから大丈夫」と太鼓判が押されていた新しいパーザは、移行のテストを試みる度に次から次へとリグレッションが発見され、移行が完全に終わるまでには、1年以上の時間を要した。結局のところ、古いパーザで、歴史的なハックと呼んで馬鹿にしていたコードが現実世界の様々な問題をカバーしていたのだった。
後日、件のテックリードにこの話をすると、製品を出荷するためには他のプロジェクトへの依存性は極力減らすこと。自分たちでコントロールできないリスクだからね、とさらっと言っていた。
もう一つの教訓は、何かを別の物に置き換える移行プロジェクト（migration project）はものすごく大変だ、ということだ。その後、いくつかの移行プロジェクトに携わったが、すぐ置き換わるものなど、一つもなかった。