Leverage OJのバックエンド書き換えはすでに進行中だった——クリーンなアーキテクチャ、適切なマイグレーション、本物の認証——しかしフロントエンドはまだオリジナルのコードベースのままだった：散在するAPI呼び出し、型安全性なし、動作させるのに創造性が必要なビルドパイプラインを持つVue 2アプリ。基礎を直すなら、屋根も直した方がいい。
この投稿はフロントエンド書き換えについてだ：なぜ行ったか、何を選んだか、持ちこたえたアーキテクチャの決定、そしてPlaywrightテストが実際に使おうとしたときにのみ現れたバグ。
あるプロジェクトは静かに負債を蓄積する。Leverage OJはそうではなかった——コンテスト中に凍結するランキングシステム、PM2クラスタリング下で壊れる認証システム、リクエストごとに提出テーブル全体をスキャンするリーダーボード、そして設定が1つ漏洩すれば完全な認証情報ダンプになるパスワードハッシュスキームという形で、大声で蓄積していた。
これは完全な書き換えの物語だ：何を置き換えたか、なぜ、そしてその過程で何を学んだか。
オリジナルのLeverage OJは、実際の制約の下で高速に進むプロジェクトだった。開発者たちは思慮深かった——アーキテクチャの決定からそれがわかる。しかし6年間の機能追加、深夜の修正、「私のマシンでは動く」パッチが不安定な塔として積み重なっていた。
