> For the complete documentation index, see [llms.txt](https://yutakatay.gitbook.io/katapedia/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yutakatay.gitbook.io/katapedia/doc/anchipatn.md). # アンチパターン ## 組織上のアンチパターン * 分析の麻痺 プロジェクトの分析段階に、不釣合いなほどの労力を費やすこと * ドル箱商品 収益が上がっている古い製品に満足して、新しい製品に無頓着になること * 委員会による設計 多数の人間が設計に関与しているが、統一された考え方がないこと * 約束の拡大 後で誤っていると判っても、決定を取り消せないこと * 閻魔の組織管理 異議を許さない、独裁的な組織管理方法 * モラル・ハザード(Moral hazard) 意思決定者が、意思決定の結果から隔離されていること * キノコ栽培的組織管理 部下に情報を伝えなかったり、誤った情報を伝える(暗所で栽培する) * 縦割り 上下方向の情報の流れが強く、組織間のつながりを禁じる組織構造 * ベンダロックイン|ベンダー依存(Vendor lock-in) 外部提供のコンポーネントに極度に依存したシステム"\[Vendor Lock-In]": ## プロジェクト管理上のアンチパターン * デスマーチ(Death March) プロジェクトが大失敗に終わることを CEO 以外全員が気づいているが、プロジェクトはデイ・ゼロ（ビッグバン）が来るまで無理やり存続させられる。あるいは、理解できない締め切りのため、従業員が深夜や休日まで勤務するよう強要される * 集団思考(Group Think) 集団の各メンバーが、同意が得られそうな領域以外の考え方を避ける * 手品師 (ソフトウェア)|手品師 未実装の機能を実装されているように見せる * ソフトウェアの肥大化 システムの後続のバージョンに、より多くの人員が必要になる ## 分析におけるアンチパターン * 傍観者効果(Bystander apathy) 要求や設計上の判断が誤っていることに気づいた人間も、多くの人々に影響を及ぼすことになるのを恐れて、何も行動しない ## ソフトウェア設計のアンチパターン * 抽象化の逆転 利用者に求められた機能を、外部から利用できるように実装しなかったため、同様の機能を上位の機能を使って再実装してしまうこと * あいまいな視点 (通例オブジェクト指向分析設計において)表現される視点を示さずに記述されたモデル * 泥団子 (ソフトウェア)|泥団子 明確な構造を持たないシステム データベース経由でプロセス間通信(IPC) * 石油精製工場 不必要に複雑な設計 * 金箔 (ソフトウェア)|金箔 もはや更なる開発を行っても価値が向上しない業務やプロジェクトに対して作業を継続すること * 内部プラットフォーム化 カスタマイズ性を持たせすぎ、基礎にしたプラットフォームの劣化したコピーとなってしまったシステム * 不適切な入力 正しくない入力の検出や扱いの失敗 * インターフェイスの肥大化 実装が極めて困難になるほどインターフェイスを強力にしてしまうこと * 魔法のボタン 抽象化を行わず、インタフェース (情報技術)|インタフェースコードの中でロジックを実装してしまうこと * 競合状態(Race hazard) イベントが想定と異なる順序で発生することを予見していないこと * 煙突システム 複雑に相互関連したコンポーネントからなる、メンテナンスが困難なシステム ## オブジェクト指向設計のアンチパターン * 貧血ドメインモデル ビジネスロジックが欠けたドメインモデル。オブジェクトは属性と振る舞いを持たなければならないので、オブジェクト指向プログラミングではない BaseBean * スーパークラスの呼び出し サブクラスがスーパークラスのオーバーライドされたメソッドを呼び出さなければならないような設計 * 円-楕円問題 変更できない型から変更可能な派生型を作成する際の問題 * 循環依存 オブジェクトやモジュール間の直接的・間接的な依存関係を不必要に取り込んでしまうこと * 定数インターフェイス インターフェイスを定数の定義に用いること 神オブジェクト 設計の一部分（クラス）に、過剰に機能を集中させること * オブジェクトのゴミ溜め 再利用に必要な（暗黙のうちの）規則に合致しない状態のオブジェクトを再利用する * オブジェクトの乱交状態 内部へのアクセスを制限なく許し、適切なカプセル化に失敗する \*ポルターガイスト (ソフトウェア)|ポルターガイスト * シーケンスによる結合 メソッドが特定の順序で呼び出される必要のあるクラス * ヨーヨー問題 過剰な断片化により、理解するのが難しい構造（たとえば継承関係） ## プログラミングのアンチパターン * 偶発的な複雑性 問題の解決に不要な複雑性を導入する * 遠隔動作 システムの大きく分散した部分同士が相互作用する * 盲信 バグ修正の正しさ、あるいはサブルーチンの結果を確認しないこと * ボートの碇 もはや使用されていない部分をそのままにしておく * ビジーウェイト(Busy spin) 何らかの事象が発生するのを待つ際に、メッセージングを使わずに、繰り返し確認することでCPUを無駄に使用する * 失敗のキャッシュ 回復された後も、エラーフラグをリセットしない * カーゴ・カルト・プログラミング パターンや方法論を理由を理解せずに用いる * 特殊事項によるコーディング 特殊なケースが認識される度に、それに対応するコードを追加する * エラーの隠蔽 エラーメッセージをユーザーに通知する前に捕捉し、隠蔽したり、安全なメッセージを見せたりする * 例外によるプログラミング プログラミング言語のエラー捕捉機構を、正常なプログラムのロジック記述に使用する * ハードコード システムの動作環境についての仮定を実装に埋め込む * 溶岩流 (ソフトウェア)|溶岩流 除去することが非常に困難で、結果が予測できないために悪い(冗長で品質の低い)コードを維持する"\[Lava Flow]": * switchとループによる順序処理 順序的な処理を、swtich文を使ったループ文の中に埋め込む マジックナンバー (プログラム)|マジックナンバー(Magic numbers) 説明のない数値をアルゴリズムで使用する \*マジックストリング * ソフトコード ビジネスロジックをソースコードではなく設定ファイルに格納する"\[Soft Coding]": * スパゲティプログラム|スパゲッティコード(Spaghetti code) 構造がほとんど理解できないようなシステム、特にコードの構造が誤っているもの ## 方法論のアンチパターン * コピー＆ペーストプログラミング 汎用的なコードを作らず、既存のコードをコピーし（改変して）使う * 金のハンマー 気に入った方法が、あらゆるところで利用できると思い込む * 発生しないであろう現象 既知のエラーを、実際に発生することはないだろうと思い込む * 最適化 (情報工学)#最適化する時期|尚早な最適化(Premature optimization) 初期の段階から効率を追求してコーディングし、良い設計やメンテナンス性を犠牲にしてしまう。時には現実の効率も悪化させてしまう * 書き直しプログラミング/偶然にもとづくプログラミング コードを徐々に修正しながら動くかどうかを確認することで、問題を解決しようとする * 車輪の再発明(Reinventing the wheel) すでに知られている適切な解決方法を採用しない * 銀の弾丸(Silver bullet) 気に入った方法が、問題の大半を解決できると思い込む * テスター駆動開発 新しい要求がバグ報告書で記述されるようなプロジェクト ## 構成管理のアンチパターン * 依存関係地獄 必要とする構成要素のバージョンによる問題 * DLL地獄(DLL hell) 特にMicrosoft Windowsにおける、ダイナミックリンクライブラリ (DLL)の不適切な管理 * 機能拡張の競合 OS X|Mac OS Xより前のMac OSにおいて、オペレーティングシステムの同じ箇所に複数の機能拡張を追加した際に発生する問題 * Javaクラスローダー#JAR地獄|JAR地獄(JAR hell) JAR (ファイルフォーマット)|JARファイルを使用しすぎ、Javaクラスローダーのモデルを理解しておらず、バージョンや配置場所の問題を生じる