先のエントリでは「何を作ったか」を書いたが、ここでは「何を避けたか」。
アンチパターンの前段階として。

（中途半端に）動作が固まった段階での処理の統一

具体的な点としては、装備中の機体パーツと武器では描画処理が微妙に違う。
武器に関しては抽象化が終わり、共通のメソッドに追い出しが成功している反面、機体パーツは半ばベタに近い書き方をしている。
これに関しては
・他ロジックへの影響がない
・上記の理由から、機体パーツを含めて抽象化して統一するコストに比してメリットが少ない
・機体パーツに関しては大きくデータ構造が変わる見込みが低い
・同時に、抽象化により軽減されるメンテナンスコストは高くない
・何より、「壊れていない」ので「修理しない」方が良い

既に試されているコードであり、将来のメンテナンスのためにコーディングスタイル的な改良を加える意味はあっても、再度抽象化のコストを支払っていくばくか（本当にいくばくか）の自己満足を得てもあまり意味はない。

満足行くまで作る

鉄の意志かギロチンの刃の如き締め切りがあればいいが、特に前者は品薄なので多分世に出ない。
無軌道にこれを自分に許した場合、マイナスの評価を恐れて永久に先延ばしし、「考えてはいるのだけれど」を言い続けてベイパーウェア（※1）になる。
今回はこれを自覚して、全てをそろえなくても動くという方向で開発、設計。ある段階で公開した。

（※1）
「蒸気のような」実態のないソフトウェア。
大は「ハイパーテキスト」という言葉を10年単位でこね回すものから、修羅の国（18歳未満お断りエンターテイメント）で発売日未定に指定席を持つタイトル、小は「企画」だけがどこかで温め続けられる同人○○○まで。

自分のドッグフードを…

いや、結局食べたのだが。というか、自分が食べたいから作ったのだが。
ただし、自分にとって良くても他の人にとってどうかはまた別の話。例えば、パーツの並び替えやパーツ一覧を閉じるボタンは当初存在しないか、おざなりな物だった。だって作り手が欲しいと気づけなかったんだもん。
他にもCSダメージ表なんかは、作る事自体は大して手間ではないけれども自分が欲しくないという理由で後回しにしていた。

ここにも落とし穴があって、欲しい物を正確に説明できる人は少ないのだ。今回はたまたま一覧表のソートについて自分で欲しい物を説明できる人がTwitterでつかまったのでさっさと直せたが、間に何かが挟まると更にひどい事になる。

データリポジトリとしてwindow.document…を使う

これはもしかしたらブレイクスルーが存在するかもしれない。

一つのやり方として、あらゆる処理中状態、あらゆる保持データをHTML要素として保持させ、処理用の内部保持データを持たないというものがある。
これはこれで魅力的で、自明に触れる場所にデータがあり、全てはそこを見て、サーバへの送信の前に何をするかもクリアになるような気がする。

が、これを実際にやったことがある身としてはおすすめできない。
画面に見えている要素、画面の状態で内部の動きまでが完全に同期できる例は少ないし、いわゆる土管型の何かでもない限りはどこかで処理状態保持のための要素を作り始め、何のためなのか分からなくなる。
手段と目的の逆転を起こさない自信があるならばいいが、おそらくそれができるならば無駄にテクニカルなこの方法を取る事自体が必要ないだろう。