あるプロジェクトは静かに負債を蓄積する。Leverage OJはそうではなかった——コンテスト中に凍結するランキングシステム、PM2クラスタリング下で壊れる認証システム、リクエストごとに提出テーブル全体をスキャンするリーダーボード、そして設定が1つ漏洩すれば完全な認証情報ダンプになるパスワードハッシュスキームという形で、大声で蓄積していた。

これは完全な書き換えの物語だ：何を置き換えたか、なぜ、そしてその過程で何を学んだか。

---

1. リファクタリングではなく書き換えを選んだ理由

技術的負債の棚卸し

オリジナルのLeverage OJは、実際の制約の下で高速に進むプロジェクトだった。開発者たちは思慮深かった——アーキテクチャの決定からそれがわかる。しかし6年間の機能追加、深夜の修正、「私のマシンでは動く」パッチが不安定な塔として積み重なっていた。

すべてのコードベースには物語がある。私がメンテナンスしているOnline JudgeプラットフォームのLeverageにもあり、それは美しくない。何年ものインクリメンタルな機能追加、深夜に押し込んだ素早い修正、そして時折の「私のマシンでは動く」ハックが本番に入った後、コードベースは小さなスタートアップに資金を提供できるほどの負債を蓄積していた。

完全な書き換えを行う決定は軽くなされなかった。書き換えはリスキーだ。「セカンドシステム効果」は本物だ。しかしコードレビューで29の異なるバグが見つかったとき——すべてのAC/WA提出カウンターが静かに間違っているものを含めて——再考を始める。