ショッピングサイトのパフォーマンス改善開発

PC向けのショッピングサイトの開発に、プロジェクトマネージャ1名、プログラマ4名からなるチームにプログラマとして参加しました。

この案件は出自（？）が特殊でした。
クライアント（サイト運営者）が某大手独立系SIerに開発を依頼したものの、納期を過ぎても完成せず、その某SIerは自社開発を諦め、当時自分が参加していたウェブ制作会社に開発を再委託したというものでした。
自分達が委託を受けた時点で画面はだいたい出来ていて各画面の基本的な機能も実装されており、進捗率は高かったのですが、独自フレームワークを採用しており、そのシステム構造が驚く程複雑で設計が悪かったです。
新たな機能を実装しようとすると既存の処理に大量な修正が発生し、高い確率でデグレが発生しました。
すでに動いてる機能もパフォーマンスが低く、クライアントの要求性能を満たそうとすると、当該処理を大幅にリライトしなければなりませんした。
納期はすでに半年以上遅れてどうにもならない状態で、某SIerはギブアップし自分達が開発を引き継ぎました。

どのように設計が悪かったか説明すると、オブジェクト指向が過度だったと言えると思います。
リクエストの度にあらゆる（ビジネスモデリング的な意味での）オブジェクトが生成され、各オブジェクトが複雑に関連していました。
ウェブアプリケーションは、特にこの案件のようなショッピングサイトの場合、基本的に業務アプリケーション（DBアプリケーション）と見なせ、その為オブジェクト中心よりデータ中心でシステム設計をした方が良いと思います。（この辺の話はSE・PG入門「データ中心指向とオブジェクト指向」に詳しいです。）
ウェブでは複雑にオブジェクトを作っても保存する先はDBだからです。
もしオブジェクト指向ならORマッパーを使えばDAOが整理されると思うのですが、この案件のシステム設計ではSQLはDAO内で独自の生成処理を経ており、ちょっと検索項目を変更しようにも、生成処理内にあるSQLの断片（復元すると数十行になる）を追う必要がありました。
また、同じ目的と思われるが微妙に異なるSQLが別のメソッドに散在していて、SQLの記述自体もコピペの繰り返しで冗長化していて、という。
開発の長期化で担当者が変遷し、担当者毎に実装の癖、コーディングスタイルが違うというお決まりの問題もありました。

結局、半年ほどかけて、なんとかもう少しで完成という所まで持って行ったのですが、ある不可抗力な事情からリリース直前に開発が中止になってしまい、案件として強制終了しました。
自分達の会社には損害はなかったのですが、後味の悪い終わりで非常に残念な気持ちがしました。
このような案件は自分の経験でも今の所唯一で、こうなる前にもっとすべき判断があったなと思います。
個人としてはアンチパターン的に勉強になってのですが。