アンチパターン

ソフトウェアエンジニアリング、プロジェクト管理、ビジネスプロセスにおけるアンチパターンは、通常は効果がなく、非常に逆効果になるリスクのある、繰り返し発生する問題に対する一般的な対応です。^{[1] [2]}この用語は、1995年にコンピュータプログラマーのアンドリュー・ケーニッヒによって造られ、書籍「デザインパターン」 （著者が非常に信頼性が高く効果的であると判断したソフトウェア開発におけるいくつかのデザインパターンを強調している）に触発され、オブジェクト指向プログラミングジャーナルの記事で初めて発表されました。^[3] 1996年にマイケル・アクロイドがObject World Westカンファレンスで発表した別の論文でも、アンチパターンが文書化されていました。^[3]

しかし、この考え方を広め、その範囲をソフトウェア設計の分野を超えてソフトウェアアーキテクチャやプロジェクト管理にまで広げたのは、 1998年の書籍「アンチパターン」^{でした。 [3]} その後、他の著者は環境、組織、文化のアンチパターンを包含するようにさらに拡張しました。^[4]

デザイン パターンの著者によると、アンチパターンには、悪い習慣、悪い実践、悪いアイデアと区別する 2 つの重要な要素があります。

1. アンチパターンとは、問題に対する適切かつ効果的な対応であるように最初は見えるものの、良い結果よりも悪い結果をもたらす、一般的に使用されるプロセス、構造、または行動パターンのことです。
2. アンチパターンが解決しようとしている問題には、別の解決策が存在します。この解決策は文書化されており、繰り返し実行可能であり、アンチパターンが効果的でない場合に効果があることが証明されています。

一般的に使用されるガイドは、パターンの場合と同様の「3つのルール」です。つまり、アンチパターンであるためには、少なくとも3回発生していることが目撃されている必要があります。^[5]

アンチパターンを文書化することは、問題領域を分析し、専門知識を獲得するための効果的な方法です。^[6]

アンチパターンの説明の中には、パターンの悪影響を単に文書化しているものもありますが、優れたアンチパターンの文書化では、代替案やアンチパターンを改善するための手段も提供されます。^[7]

ソフトウェアエンジニアリングにおけるアンチパターンには、ビッグボールオブマッド（欠如）デザイン、ゴッドオブジェクト（制御が複数のクラスに分散されるのではなく、単一のクラスがプログラム内のすべての制御を処理する）、マジックナンバー（意味が説明されていない一意の値、または名前付き定数に置き換えられる可能性のある複数の出現）、ポルターガイスト（クラスの他のメソッドを呼び出すためだけに存在する一時的なコントローラークラス）などがあります。^[7]

これは、認識可能なアーキテクチャが欠如しているソフトウェア システムを示します。ソフトウェア エンジニアリングの観点からは望ましくないですが、ビジネス上のプレッシャー、開発者の離職、コードのエントロピーなどの理由から、このようなシステムは実際には一般的です。

この用語は、ブライアン・フットとジョセフ・ヨーダーが 1997 年に発表した同名の論文で広く知られるようになりました。この論文では次のように定義されています。

大きな泥団子は、無秩序に構造化され、無秩序に広がり、ずさんで、ダクトテープと梱包用ワイヤーでできた、スパゲッティ コードのジャングルです。これらのシステムは、無秩序な成長と、繰り返し行われる便宜的な修復の明らかな兆候を示しています。情報は、システムの離れた要素間で無差別に共有され、重要な情報のほとんどすべてがグローバルになったり、重複したりすることがよくあります。

システムの全体的な構造は、これまで明確に定義されていなかった可能性があります。

もしそうなら、認識できないほどに侵食されているかもしれない。少しでもアーキテクチャの感覚を持つプログラマーは、こうした泥沼を避けている。アーキテクチャに関心がなく、おそらく、こうした壊れかけた堤防の穴を塞ぐという日々の雑用の惰性に満足している人だけが、こうしたシステムで作業することに満足している。

— ブライアン・フットとジョセフ・ヨーダー、Big Ball of Mud。第 4 回プログラムパターン言語会議 (PLoP '97/EuroPLoP '97) イリノイ州モンティセロ、1997 年 9 月

フットとヨーダーは、この種の建築を「大きな泥の塊」と呼ぶことをブライアン・マリックに依頼した。^[8]

『アンチパターン』の本に含まれるプロジェクト管理のアンチパターンには次のものがあります。

• ブロウハード・ジャンボリー（業界の専門家が多すぎる）
• 分析麻痺
• Viewgraph エンジニアリング (プレゼンテーションの作成に時間がかかりすぎて、実際のソフトウェアに十分な時間が取れない)
• 計画による死（同様に、計画しすぎること）
• 成功への恐怖（プロジェクト完了間近の不合理な恐怖）
• コーンコブ（人とのトラブル）
• 知的暴力（専門用語や難解な技術を使った脅迫）
• 非合理的な管理（悪い管理習慣）
• 煙と鏡（営業担当者によるデモやプロトタイプの過剰な使用）
• 壁を越えて投げる（賛同を得ずに流行のソフトウェア エンジニアリング手法を開発者に強制する）
• 消防訓練（短い危機を挟んで長い単調な時間が続く）
• 確執（マネージャー間の対立）
• 電子メールは危険です（不適切な電子メールメッセージによって生じる状況）。^[4]

• コード臭 – コンピュータプログラミングの特性
• デザインの匂い – コンピュータプログラミング用語
• ダークパターン – 欺瞞的なユーザーインターフェースデザイン
• ソフトウェア開発哲学のリスト
• 静的コード解析ツールの一覧
• ソフトウェアの腐敗 – ソフトウェアの劣化のプロセス
• ソフトウェアピーターの原則 – 複雑で失敗するプロジェクトを表すエンジニアリング用語
• 能力未熟モデル
• ISO/IEC 29110 : 小規模エンティティ (VSE) 向けソフトウェア ライフサイクル プロファイルとガイドライン
• イノベーションのジレンマ – 1997 年、クレイトン・M・クリステンセン著

• Koenig, Andrew (1995 年 3 月 - 4 月)。「パターンとアンチパターン」。オブジェクト指向プログラミングジャーナル。8 (1): 46 - 48。
  • 後に再版された：Rising, Linda (1998). The patterns handbook: Techniques, strategies, and applications. Cambridge, UK: Cambridge University Press. p. 387. ISBN 0-521-64818-1アンチパターンはパターンと似ていますが、解決策ではなく、表面的には解決策のように見えるが実際には解決策ではないものを提供するという点が異なります。
• Laplante, Phillip A.; Neill , Colin J. (2005).アンチパターン: 識別、リファクタリング、管理。Auerbach Publications。ISBN 0-8493-2994-9。
• Brown, William J.; Malveau, Raphael C.; McCormick, Hays W .; Thomas, Scott W. (2000)。 Hudson, Theresa Hudson (編)。プロジェクト管理におけるアンチパターン。John Wiley & Sons。ISBN 0-471-36366-9。
• Stamelos, Ioannis (2010年1 月)。「ソフトウェア プロジェクト管理のアンチパターン」。システムおよびソフトウェア ジャーナル。83 (1): 52–59。doi :10.1016/j.jss.2009.09.016 。

ウィキメディア・コモンズには、アンチパターンに関連するメディアがあります。

• WikiWikiWebのアンチパターン