シナリオを説明する正式なアンチパターンはありますか？

一部のコードは、Excelスプレッドシート（​​Office Interop）を生成するために記述されています。

• コードのパフォーマンスが非常に悪い。
  
  • サブシステムは、夜間にファイルを生成するように設計されています。夜間のパフォーマンスは気になりません。
    • 選択したパラメーターのセットに応じて、利用可能な100の異なるファイルから正しいファイルを選択する関数が作成されます。
    • 物理ファイルが存在するため、これらのファイルをバックアップするためにアーカイブシステムが追加されます（アーカイブする理由はありません。これらのファイルはオンザフライで生成する必要があります）。
    • このシステムには構成ファイルが含まれていません。代わりに、コードが実行されているサーバーを単に反映するハードコーディングされた「サーバーピッカー」関数があります。
    • このサービスをサポートして実行するには、スケジュールされたタスクが必要です。

これは、1つの問題に要約されます。元のコードは、実稼働環境で実行するにはパフォーマンスが低すぎます。

パフォーマンスの問題が解決されていれば、サブシステムとその後のアーカイブシステム、「ファイルピッカーファクトリー機能」、ハードコードされた障害ポイント、およびスケジュールされたタスクのメンテナンスと追加された障害ポイントが存在する必要はありません。

これは、「カスケードエラー」です。元の問題は、より多くの不良コード、より多くの不良ソリューション、および不要なオーバーヘッドにつながりました。それを説明する正式なアンチパターンまたは一般的な用語はありますか？

溶岩流？

コンピュータプログラミングの専門用語では、溶岩流は、最適ではない条件下で記述されたコンピュータコードがプロダクションに入れられ、まだ開発中の状態で追加される問題です。

Perl Design Wikiから：Lava Flowは「コード...が噴出して永続的になると、考古学的な多様性のアーキテクチャー上の特徴になります。問題はなく、その下にあるものを変更する望みもなく、構造の上に構築されます。既存のコードは歴史的な好奇心と見なされています。」

多くの場合、システムを運用環境に置くと、元の不完全な設計との下位互換性（多くの追加コンポーネントがそれに依存するようになるため）を維持する必要が生じます。

溶岩流は、プロジェクトに取り組んでいる開発チームの変更によって悪化することがよくあります。労働者がプロジェクトに出入りすると、システムの側面の目的に関する知識が失われる可能性があり、これらの要素をクリーンアップするのではなく、回避され、システムの複雑さと混乱が増大します。

溶岩流はアンチパターンと見なされます。これは、一般的に遭遇する現象であり、設計の悪化につながります。

これがアンチパターンかどうかはわかりません。すべてのアンチパターンと同様に、良い考えだと思った人は誰でも間違っていたというあなたの言葉を受け入れなければなりませんが、この場合はそれはもっともらしいようで、私はあなたの言葉をその言葉に取り入れますので、それは問題ではありません。

問題は、アンチパターンが有用であるためには、ある種の一般的な落とし穴とそれを回避する方法を説明する必要があるということです。この場合、パフォーマンスを向上させることができたとしても、パフォーマンスが低下するコードの回避策を見つけることになります。

アンチパターンとしての私見のそれの問題は、それについて知ることはあまり価値がないように思われるということです。これを行った人はだれもがすでにそれをより良くする方法を知るのは素晴らしいことだとすでに理解しているので、彼らはそれを行う方法を知っていてはいけません。したがって、アンチパターンとしての一般的な状況について聞いても、実際には役に立たなかったでしょう。

それを説明する一般的な用語としては、「カスケード障害」は、あなたが提案したように、かなりうまく機能します。そもそも意味のないミッションで資格のない人が好きな私が好む用語はスネークハンティングですが、この状況ではそれは厳しすぎるようです。（しかし、私が知っている破滅した企業の最良の描写であるため、とにかく私はリンクをいくらか不当に投げます。）

これが役立つかどうかはわかりませんが、多くの場合、オフィスオートメーションは特殊なケースです。

Officeオートメーションは、ユーザーのデスクトップから自動化する必要がある場合、通常はこの方法で行われます（特に.net Webサイトの場合）。Officeオートメーションのドキュメントは、ヘッドレスで実行するとOffice相互運用ツールに不適切なリークが発生することを正しく警告するためです。そのツールキットを使用してOfficeドキュメントを生成するためにヘッドレスプロセスを書くことを余儀なくされました。メモリを取り戻すために定期的に殺す必要があったため、犠牲サービスを呼び出しました。

残念ながら、あなたが説明している内容をアーカイブすることは、場合によってはベストプラクティスです。

リンク：http : //support.microsoft.com/kb/257757