アンチパターン

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

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

1. 概要
-----

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

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

動作やプロセス、構造についての繰り返されるパターンで、最初は有益だと思えるが、最終的に悪い結果をもたらすもので、
リファクタリングするための方法が存在し、文書化され、実例で証明されており、再現可能であること数多く挙げられたアンチパターンは、矛盾した言葉を侮蔑的に用いた新しい用語で呼ばれ、可能なら避けられるべき、単なる誤り、未解決の問題、悪習以上の意味を持っている。「落とし穴」や「暗黒のパターン」とも呼ばれる別の呼び方があるが、これは、悪い問題の解決策が再発明されることを指す。こうしたアンチパターンの候補は、公式にアンチパターンとは考えられない。

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

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

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

肥満児肥大化したオブジェクトお邪魔妖怪 オブジェクトに情報を渡すことだけが目的のオブジェクト溶岩流除去することが非常に困難で、結果が予測できないために悪いコードを維持する打出の小槌気に入った方法が、あらゆるところで利用できると思い込むスパゲッティコード 構造がほとんど理解できないようなシステム、特にコードの構造が誤っているもの切り貼りプログラミング汎用的なコードを作らず、既存のコードをコピーし使う曖昧な視点表現される視点を示さずに記述されたモデル入力クラッジ正しくない入力の検出や扱いの失敗暗室栽培部下に情報を伝えなかったり、誤った情報を伝える

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

システムのおんぼろ煙突化複雑に相互関連したコンポーネントからなる、メンテナンスが困難なシステム砂上の楼閣 外部提供のコンポーネントに極度に依存したシステム組織硬直多数の人間が設計に関与しているが、統一された考え方がないこと車輪の再発明 すでに知られている適切な解決方法を採用しない

2.3. 組織上のアンチパターン
----------------

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

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

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

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

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

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

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

2.6. 方法論のアンチパターン
----------------

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

2.7. 構成管理のアンチパターン
-----------------

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

3. 脚注・出典
--------

4. 参考文献
-------

和書

5. 関連項目
-------

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

6. 外部リンク
--------

[1] at WikiWikiWeb
[2]
[3] Web site for the AntiPatterns book
[4]