アンチパターン

アンチパターン (英: anti-pattern) とは、ある問題に対する、不適切な解決策を分類したものである 。語源は、ソフトウェア工学におけるデザインパターンである。

主に失敗した開発プロセスに焦点を当てて失敗に陥るパターンを類型化する。そうすることで、そのような事例の早期発見と対応策に関しての提案を目的とする。

競合状態が発生するソフトウェア開発や保守性の低いソースコードなどが主な例である。

アンチパターンという呼び方は、Andrew Koenigが1995年に作り出したもので、 後に書籍The patterns handbook で再掲された。

ギャング・オブ・フォーの書籍『オブジェクト指向における再利用のためのデザインパターン』からヒントを得て、書籍AntiPatternsが出版され、3年後には「アンチパターン」という単語はソフトウェアの設計から一般的な社会の相互作用についても広く用いられるようになった。AntiPatternsの著者によれば、アンチパターンと単なる悪癖、悪習などと区別するには二つの要素があるという。

• 動作やプロセス、構造についての繰り返されるパターンで、最初は有益だと思えるが、最終的に悪い結果をもたらすもので、
• リファクタリングするための方法が存在し、文書化され、実例で証明されており、再現可能であること

数多く挙げられたアンチパターンは、矛盾した言葉を侮蔑的に用いた新しい用語で呼ばれ、可能なら避けられるべき、単なる誤り、未解決の問題、悪習以上の意味を持っている。「落とし穴」や「暗黒のパターン」とも呼ばれる別の呼び方があるが、これは、悪い問題の解決策が再発明されることを指す。こうしたアンチパターンの候補は、公式にアンチパターンとは考えられない。

繰り返される間違いを記述することによって、繰り返しにつながる力学的な構造や、誤ったパターンを取り除くようリファクタリングする方法を学習することができる。

よく知られるアンチパターン

組織上のアンチパターン

分析の麻痺(Analysis paralysis)

プロジェクトの分析段階に、不釣合いなほどの労力を費やすこと

ドル箱商品(Cash cow)

収益が上がっている古い製品に満足して、新しい製品に無頓着になること

委員会による設計(Design by committee)

多数の人間が設計に関与しているが、統一された考え方がないこと

約束の拡大(Escalation of commitment)

後で誤っていると判っても、決定を取り消せないこと

閻魔の組織管理(Management by perkele)

異議を許さない、独裁的な組織管理方法

モラル・ハザード(Moral hazard)

意思決定者が、意思決定の結果から隔離されていること

キノコ栽培的組織管理(Mushroom management)

部下に情報を伝えなかったり、誤った情報を伝える(暗所で栽培する)

縦割り(Stovepipe)

上下方向の情報の流れが強く、組織間のつながりを禁じる組織構造

ベンダー依存(Vendor lock-in)

外部提供のコンポーネントに極度に依存したシステム

プロジェクト管理上のアンチパターン

デスマーチ(Death March)

プロジェクトが大失敗に終わることを CEO 以外全員が気づいているが、プロジェクトはデイ・ゼロ（ビッグバン）が来るまで無理やり存続させられる。あるいは、理解できない締め切りのため、従業員が深夜や休日まで勤務するよう強要される

集団思考(Group Think)

集団の各メンバーが、同意が得られそうな領域以外の考え方を避ける

手品師(Smoke and mirrors)

未実装の機能を実装されているように見せる

ソフトウェアの肥大化(Software Bloat)

システムの後続のバージョンに、より多くの人員が必要になる

分析におけるアンチパターン

傍観者効果(Bystander apathy)

要求や設計上の判断が誤っていることに気づいた人間も、多くの人々に影響を及ぼすことになるのを恐れて、何も行動しない

ソフトウェア設計のアンチパターン

抽象化の逆転(Abstraction inversion)

利用者に求められた機能を、外部から利用できるように実装しなかったため、同様の機能を上位の機能を使って再実装してしまうこと

あいまいな視点(Ambiguous viewpoint)

(通例オブジェクト指向分析設計において)表現される視点を示さずに記述されたモデル

泥団子(Big ball of mud)

明確な構造を持たないシステム

• データベース経由でプロセス間通信(IPC)(Database-as-IPC):軽量なプロセス間通信方式を使用すべき場面で、データベースをプロセス間通信のメッセージキューとして使ってしまうこと

石油精製工場(Gas factory)

不必要に複雑な設計

金箔(Gold plating)

もはや更なる開発を行っても価値が向上しない業務やプロジェクトに対して作業を継続すること

内部プラットフォーム化(Inner-platform effect)

カスタマイズ性を持たせすぎ、基礎にしたプラットフォームの劣化したコピーとなってしまったシステム

不適切な入力(Input kludge)

正しくない入力の検出や扱いの失敗

インターフェイスの肥大化(Interface bloat)

実装が極めて困難になるほどインターフェイスを強力にしてしまうこと

魔法のボタン(Magic pushbutton)

抽象化を行わず、インタフェースコードの中でロジックを実装してしまうこと

競合状態(Race hazard)

イベントが想定と異なる順序で発生することを予見していないこと

煙突システム(Stovepipe system)

複雑に相互関連したコンポーネントからなる、メンテナンスが困難なシステム

オブジェクト指向設計のアンチパターン

貧血ドメインモデル(Anemic Domain Model)

ビジネスロジックが欠けたドメインモデル。オブジェクトは属性と振る舞いを持たなければならないので、オブジェクト指向プログラミングではない

• BaseBean(BaseBean):ユーティリティクラスに処理を委譲せず、継承して使ってしまうこと

スーパークラスの呼び出し(Call super)

サブクラスがスーパークラスのオーバーライドされたメソッドを呼び出さなければならないような設計

円-楕円問題(Circle-ellipse problem)

変更できない型から変更可能な派生型を作成する際の問題

循環依存(Circular dependency)

オブジェクトやモジュール間の直接的・間接的な依存関係を不必要に取り込んでしまうこと

定数インターフェイス(Constant interface)

インターフェイスを定数の定義に用いること

神オブジェクト(God object)

設計の一部分（クラス）に、過剰に機能を集中させること

オブジェクトのゴミ溜め(Object cesspool)

再利用に必要な（暗黙のうちの）規則に合致しない状態のオブジェクトを再利用する

オブジェクトの乱交状態(Object orgy)

内部へのアクセスを制限なく許し、適切なカプセル化に失敗する

• ポルターガイスト(Poltergeist)オブジェクトに情報を渡すだけが目的のオブジェクト

シーケンスによる結合(Sequential coupling)

メソッドが特定の順序で呼び出される必要のあるクラス

ヨーヨー問題(Yo-yo problem)

過剰な断片化により、理解するのが難しい構造（たとえば継承関係）

プログラミングのアンチパターン

偶発的な複雑性(Accidental complexity)

問題の解決に不要な複雑性を導入する

遠隔動作(Action at a distance)

システムの大きく分散した部分同士が相互作用する

盲信(Blind faith)

バグ修正の正しさ、あるいはサブルーチンの結果を確認しないこと

ボートの碇(Boat anchor)

もはや使用されていない部分をそのままにしておく

ビジーウェイト(Busy spin)

何らかの事象が発生するのを待つ際に、メッセージングを使わずに、繰り返し確認することでCPUを無駄に使用する

失敗のキャッシュ(Caching failure)

回復された後も、エラーフラグをリセットしない

カーゴ・カルト・プログラミング(Cargo cult programming)

パターンや方法論を理由を理解せずに用いる

特殊事項によるコーディング(Coding by exception)

特殊なケースが認識される度に、それに対応するコードを追加する

エラーの隠蔽(Error hiding)

エラーメッセージをユーザーに通知する前に捕捉し、隠蔽したり、安全なメッセージを見せたりする

例外によるプログラミング(Expection handling)

プログラミング言語のエラー捕捉機構を、正常なプログラムのロジック記述に使用する

ハードコード(Hard code)

システムの動作環境についての仮定を実装に埋め込む

溶岩流(Lava flow)

除去することが非常に困難で、結果が予測できないために悪い(冗長で品質の低い)コードを維持する

switchとループによる順序処理(Loop-switch sequence)

順序的な処理を、swtich文を使ったループ文の中に埋め込む

マジックナンバー(Magic numbers)

説明のない数値をアルゴリズムで使用する

• マジックストリング(Magic string):イベントの比較などのために、リテラルの文字列を用いる

ソフトコード(Softcoding)

ビジネスロジックをソースコードではなく設定ファイルに格納する

スパゲッティコード(Spaghetti code)

構造がほとんど理解できないようなシステム、特にコードの構造が誤っているもの

方法論のアンチパターン

コピー＆ペーストプログラミング(Copy and paste programming)

汎用的なコードを作らず、既存のコードをコピーし（改変して）使う

金のハンマー(Golden hammer)

気に入った方法が、あらゆるところで利用できると思い込む(銀の弾丸も参照)

発生しないであろう現象(Improbability factor)

既知のエラーを、実際に発生することはないだろうと思い込む

尚早な最適化(Premature optimization)

初期の段階から効率を追求してコーディングし、良い設計やメンテナンス性を犠牲にしてしまう。時には現実の効率も悪化させてしまう

書き直しプログラミング/偶然にもとづくプログラミング(Programming by permutation)

コードを徐々に修正しながら動くかどうかを確認することで、問題を解決しようとする

車輪の再発明(Reinventing the wheel)

すでに知られている適切な解決方法を採用しない

銀の弾丸(Silver bullet)

気に入った方法が、問題の大半を解決できると思い込む

テスター駆動開発(Tester Driven Development)

新しい要求がバグ報告書で記述されるようなプロジェクト

構成管理のアンチパターン

依存関係地獄(Dependency hell)

必要とする構成要素のバージョンによる問題

DLL地獄(DLL hell)

特にMicrosoft Windowsにおける、ダイナミックリンクライブラリ (DLL)の不適切な管理

機能拡張の競合(Extension conflict)

Mac OS Xより前のMac OSにおいて、オペレーティングシステムの同じ箇所に複数の機能拡張を追加した際に発生する問題

JAR地獄(JAR hell)

JARファイルを使用しすぎ、Javaクラスローダーのモデルを理解しておらず、バージョンや配置場所の問題を生じる

関連項目

• コードの臭い (Code smell)– 悪いプログラミングの兆候
• ソフトウェア開発の哲学(英語) – approaches, styles, maxims and philosophies for software development
• ソフトウェアにおけるピーターの法則

外部リンク

• Anti-pattern at WikiWikiWeb
• Anti-patterns catalog
• AntiPatterns.com Web site for the AntiPatterns book
• Patterns of Toxic Behavior

書籍

• 『アンチパターン ソフトウェア危篤患者の救出』、William J. Brown (著) 、Raphael C. Malveau (著) 、Hays W."Skip" McCormick III (著) 、Thomas J. Mowbray (著) 、岩谷宏 (訳) 、ソフトバンククリエイティブ、2002年 (初版は1999年) 、ISBN 978-4797321388
• 『ソフトウェア構成管理の悪夢 アンチパターン』、William J. Brown (著) 、 Scott W. Thomas (著) 、Hays W."Skip" McCormick III (著) 、岩谷宏 (訳) 、ソフトバンククリエイティブ、1999年 、ISBN 978-4797311303