アンチパターン

ソフトウェア開発におけるアンチパターン (英: anti-pattern) とは、必ず否定的な結果に導く、しかも一般的に良く見られる開発方式を記述する文献形式を言う^[1]。その内容は、基本的には、否定的な開発方式の一般的な形、主原因、症状、重症化した時の結果、そしてその対策の記述からなる^[2]。

デザインパターンを補完・拡張する関係にあるもので、多くの開発者が繰り返すソフトウェア開発の錯誤を明確に定義することにより、開発や導入を阻害する一般的で再発性の高い障害要因の検知と克服を支援することが目的である^[3]^[4]。

概要

ある問題に対する、不適切な解決策を分類したものをアンチパターンと言う^[5]^[6]。アンチパターンという呼び方は、アンドリュー・ケーニッヒ（英語版）が1995年に作り出したもので^[7]、後に書籍The patterns handbook^[8]で再掲された。

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

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

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

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

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

ソフトウェア開発のアンチパターン

肥満児（The Blob）: 肥大化したオブジェクト
お邪魔妖怪（英語版） (poltergeist): オブジェクトに情報を渡すことだけが目的のオブジェクト
溶岩流（lava flow）: 除去することが非常に困難で、結果が予測できないために悪い(冗長で品質の低い)コードを維持する^[9]^[10]
打出の小槌（golden hammer）: 気に入った方法が、あらゆるところで利用できると思い込む（銀の弾丸も参照）
スパゲッティコード (spaghetti code): 構造がほとんど理解できないようなシステム、特にコードの構造が誤っているもの
切り貼りプログラミング（英語版）（copy and paste programming）: 汎用的なコードを作らず、既存のコードをコピーし（改変して）使う

曖昧な視点（英語版）（ambiguous viewpoint）: (通例オブジェクト指向分析設計において)表現される視点を示さずに記述されたモデル
入力クラッジ（英語版）（input kludge）: 正しくない入力の検出や扱いの失敗
暗室栽培（英語版）（mushroom management）: 部下に情報を伝えなかったり、誤った情報を伝える(暗所で栽培する)

ソフトウェア基盤のアンチパターン

システムのおんぼろ煙突化（英語版）（stovepipe system）: 複雑に相互関連したコンポーネントからなる、メンテナンスが困難なシステム
砂上の楼閣 (vendor lock-in): 外部提供のコンポーネントに極度に依存したシステム^[11]
組織硬直（英語版）（design by committee）: 多数の人間が設計に関与しているが、統一された考え方がないこと
車輪の再発明 (reinventing the wheel): すでに知られている適切な解決方法を採用しない

組織上のアンチパターン

ドル箱商品（英語版）: 収益が上がっている古い製品に満足して、新しい製品に無頓着になること
約束の拡大（英語版）: 後で誤っていると判っても、決定を取り消せないこと
閻魔の組織管理（英語版）: 異議を許さない、独裁的な組織管理方法
モラル・ハザード: 意思決定者が、意思決定の結果から隔離されていること
縦割り（英語版）: 上下方向の情報の流れが強く、組織間のつながりを禁じる組織構造

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

分析地獄（英語版）（analysis paralysis）: プロジェクトの分析段階に、不釣合いなほどの労力を費やすこと
デスマーチ (Death March): プロジェクトが大失敗に終わることを CEO 以外全員が気づいているが、プロジェクトはデイ・ゼロ（ビッグバン）が来るまで無理やり存続させられる。あるいは、理解できない締め切りのため、従業員が深夜や休日まで勤務するよう強要される
集団思考 (Group Think): 集団の各メンバーが、同意が得られそうな領域以外の考え方を避ける
手品師 (ソフトウェア)（英語版）: 未実装の機能を実装されているように見せる
ソフトウェアの肥大化 (Software Bloat): システムの後続のバージョンに、より多くの人員が必要になる
スコープ・クリープ (Scope creep): プロジェクトの開始後に、プロジェクトのスコープ（範囲）が継続的に変化または適切な管理無しで増大する

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

貧血ドメインモデル（英語版）: ビジネスロジックが欠けたドメインモデル。オブジェクトは属性と振る舞いを持たなければならないので、オブジェクト指向プログラミングではない
BaseBean（英語版）: ユーティリティクラスに処理を委譲せず、継承して使ってしまうこと
スーパークラスの呼び出し（英語版）: サブクラスがスーパークラスのオーバーライドされたメソッドを呼び出さなければならないような設計
円-楕円問題（英語版）: 変更できない型から変更可能な派生型を作成する際の問題
循環依存（英語版）: オブジェクトやモジュール間の直接的・間接的な依存関係を不必要に取り込んでしまうこと
定数インターフェイス（英語版）: インターフェイスを定数の定義に用いること
神オブジェクト（英語版）: 設計の一部分（クラス）に、過剰に機能を集中させること
オブジェクトのゴミ溜め（英語版）: 再利用に必要な（暗黙のうちの）規則に合致しない状態のオブジェクトを再利用する
オブジェクトの乱交状態（英語版）: 内部へのアクセスを制限なく許し、適切なカプセル化に失敗する
シーケンスによる結合（英語版）: メソッドが特定の順序で呼び出される必要のあるクラス
ヨーヨー問題: 過剰な断片化により、理解するのが難しい構造（たとえば継承関係）

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

偶発的な複雑性（英語版）: 問題の解決に不要な複雑性を導入する
遠隔動作（英語版）: システムの大きく分散した部分同士が相互作用する
盲信（英語版）: バグ修正の正しさ、あるいはサブルーチンの結果を確認しないこと
ボートの碇（英語版）: もはや使用されていない部分をそのままにしておく
ビジーウェイト (Busy spin): 何らかの事象が発生するのを待つ際に、メッセージングを使わずに、繰り返し確認することでCPUを無駄に使用する
失敗のキャッシュ（英語版）: 回復された後も、エラーフラグをリセットしない
カーゴ・カルト・プログラミング (Cargo cult programming): パターンや方法論を理由を理解せずに用いる
特殊事項によるコーディング（英語版）: 特殊なケースが認識される度に、それに対応するコードを追加する
エラーの隠蔽（英語版）: エラーメッセージをユーザーに通知する前に捕捉し、隠蔽したり、安全なメッセージを見せたりする
例外によるプログラミング（英語版）: プログラミング言語のエラー捕捉機構を、正常なプログラムのロジック記述に使用する
ハードコード: システムの動作環境についての仮定を実装に埋め込む
switchとループによる順序処理（英語版）: switch文を使った順序的な処理を、ループ文の中に埋め込む
マジックナンバー (Magic numbers): 説明のない数値をアルゴリズムで使用する
マジックストリング (Magic string): イベントの比較などのために、リテラルの文字列を用いる
ソフトコーディング (Softcoding): ビジネスロジックをソースコードではなく設定ファイルに格納する^[12]

方法論のアンチパターン

発生しないであろう現象（英語版）: 既知のエラーを、実際に発生することはないだろうと思い込む
尚早な最適化 (Premature optimization): 初期の段階から効率を追求してコーディングし、良い設計やメンテナンス性を犠牲にしてしまう。時には現実の効率も悪化させてしまう
書き直しプログラミング（英語版）/偶然にもとづくプログラミング: コードを徐々に修正しながら動くかどうかを確認することで、問題を解決しようとする
銀の弾丸 (Silver bullet): 気に入った方法が、問題の大半を解決できると思い込む
テスター駆動開発（英語版）: 新しい要求がバグ報告書で記述されるようなプロジェクト

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

依存関係地獄（英語版）: 必要とする構成要素のバージョンによる問題
DLL地獄 (DLL hell): 特にMicrosoft Windowsにおける、ダイナミックリンクライブラリ (DLL) の不適切な管理
機能拡張の競合（英語版）: Classic Mac OSにおいて、オペレーティングシステムの同じ箇所に異なる機能拡張を追加しようとした際に発生する問題
JAR地獄 (JAR hell): JARファイルを使用しすぎ、Javaクラスローダーのモデルを理解しておらず、バージョンや配置場所の問題を生じる

脚注・出典

^ アンチパターン(2002) p.9
^ 競合状態が発生するソフトウェア開発や保守性の低いソースコードなどが主な例である。
^ アンチパターン(2002) p.xxiii
^ 問題解決のための戦略の立案と実施をすることがアンチパターンの目的であり、ソフトウェア開発における不味いやり方に焦点を当てることが目的ではない。加えて、アンチパターンを破壊的な方向に利用することには社会的な危険が伴うと言われる。形の正しいアンチパターンは、否定的な解から肯定的な解への移行を定義しており、否定的な解のみを記述しているものはアンチパターンもどき（pseudo-AntiPattern）と呼ばれ区別される。アンチパターン(2002) p.79,80,89
^ Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. pp. 225. ISBN 0-201-72219-4 "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
^ Scott W. Ambler (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. pp. 4. ISBN 0-521-64568-9 "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
^ Koenig, Andrew (March/April 1995). “Patterns and Antipatterns”. Journal of Object-Oriented Programming 8, (1): 46?48.
^ Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. pp. 387. ISBN 0-521-64818-1 「アンチパターンは一般的なパターンとよく似ており、パターンが問題の解決方法を提供するが、アンチパターンは一見問題の解決方法に見えて実際はそうではない」
^ Lava Flow at antipatterns.com
^ Undocumented 'lava flow' antipatterns complicate process
^ Vendor Lock-In at antipatterns.com
^ Soft Coding

参考文献

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

外部リンク

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

[1] アンチパターン(2002) p.9

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

[3] アンチパターン(2002) p.xxiii

[4] 問題解決のための戦略の立案と実施をすることがアンチパターンの目的であり、ソフトウェア開発における不味いやり方に焦点を当てることが目的ではない。加えて、アンチパターンを破壊的な方向に利用することには社会的な危険が伴うと言われる。形の正しいアンチパターンは、否定的な解から肯定的な解への移行を定義しており、否定的な解のみを記述しているものはアンチパターンもどき（pseudo-AntiPattern）と呼ばれ区別される。アンチパターン(2002) p.79,80,89

[5] Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. pp. 225. ISBN 0-201-72219-4 "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."

[6] Scott W. Ambler (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. pp. 4. ISBN 0-521-64568-9 "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."

[7] Koenig, Andrew (March/April 1995). “Patterns and Antipatterns”. Journal of Object-Oriented Programming 8, (1): 46?48.

[8] Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. pp. 387. ISBN 0-521-64818-1 「アンチパターンは一般的なパターンとよく似ており、パターンが問題の解決方法を提供するが、アンチパターンは一見問題の解決方法に見えて実際はそうではない」

[9] Lava Flow at antipatterns.com

[10] Undocumented 'lava flow' antipatterns complicate process

[11] Vendor Lock-In at antipatterns.com

[12] Soft Coding

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

概要