アンチパターン

アンチパターンは、自分の足を撃つための実証済みの方法です。アンチパターンという用語は Andrew Koenig によって造られたもので、それらについて読むのはとても楽しいものです。

1994 年に出版された本「デザイン パターン:再利用可能なオブジェクト指向ソフトウェアの要素」(デザイン パターン) では、アンチパターンを「一般的に使用されるプロセス、構造、またはアクションのパターン」と定義しています。問題に対する適切かつ効果的な対応は、良い結果よりも悪い結果の方が多い ." 1998 年に、書籍「アンチパターン:危機に瀕したソフトウェア、アーキテクチャ、およびプロジェクトのリファクタリング」(アンチパターン) によって、この用語が広く知られるようになりました。最初は有益に見えるプロジェクト管理ですが、最終的には期待される利点を上回る悪い結果をもたらします。"

簡単に言うと、アンチパターンは、良い結果よりも悪い結果をもたらす一般的に使用される慣行です .

次の段落では、アンチパターンに関するいくつかの理論を非常に簡潔に説明します。この理論は、「AntiPatterns:Refactoring Software, Architectures, and Projects in Crisis」という本に基づいています。詳細については、引用された本をお読みください。

アンチパターン:危機におけるソフトウェア、アーキテクチャ、プロジェクトのリファクタリング

アンチパターンは、文学的な形式であるデザインパターンに似ており、一般的に発生する問題のコミュニケーションと問題の説明を簡素化します。多くの場合、それは間違ったコンテキストで適用されたパターンです。主な原因は次のとおりです。ソフトウェア開発の 7 つの罪:

  • 欲望
  • 暴食
  • 強欲
  • ナマケモノ
  • 怒り
  • 嫉妬
  • プライド

それどころか、ソフトウェア設計では、決定を下す際に次の基本的な力を考慮する必要があります。

  • 機能管理
  • パフォーマンス管理 (非機能要件)
  • 複雑性管理
  • 変更管理
  • IT リソース管理
  • 技術移転管理

各アンチパターンには、次の 3 つのコンポーネントがあります。

  • 名前:否定的な意味合いを持つ一意の名前
  • 問題:悪い結果をもたらす一般的な慣行
  • リファクタリング:アンチパターンの回避またはその影響の最小化

AntiPatterns という本には、次の 3 つの典型的なドメインが示されています。

<オール>
  • ソフトウェア開発 :システムの拡張と保守には適切なソフトウェア構造が不可欠ですが、ソフトウェア開発は混沌とした作業になることがよくあります。ソフトウェア リファクタリングは、ソフトウェア構造を改善するための鍵です。
  • ソフトウェア アーキテクチャ :アーキテクチャは、システムのシステム レベルおよびエンタープライズ レベルの構造に焦点を当てています。優れたアーキテクチャは、システム開発の成功の鍵となる要素であり、アーキテクチャ主導のソフトウェア開発によって実現できます。
  • プロジェクト管理 :現代のソフトウェア エンジニアリングは、主に人間のコミュニケーションに依存しています。不適切なプロジェクト管理は、ソフトウェア プロセスに大きな損害を与える可能性があります。アンチパターンに対する解決策は、非生産的な境界を排除し、エンジニアが独自の決定を下せるようにすることです。

    • さて、楽しい部分に。ここにいくつかのアンチパターンがあります。私は Anti-Patterns book の分類を使用していますが、他のソースからのアンチパターンも取り入れています。さらに、提示されたアンチパターンの理由をいくつか提示します。

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

    • カットアンドペースト プログラミング (コピー アンド ペーストとも呼ばれます):ソース ステートメントをコピーしてコードを再利用すると、重大な保守上の問題が発生します。 (アンチパターンから)。その理由は、会社にコードの再利用文化がないためかもしれません。また、抽象化の欠如やコミュニケーションの欠落が原因である可能性もあります。
    • 溶岩流 (別名デッド コード):デッド コードと忘れられた設計情報は、(AntiPatterns から) 絶えず変化する設計で凍結されます。新機能の開発に重点が置かれています。コードをリファクタリングする時間はありません。
    • タマネギ :新しいコードが古いコードにラップされます。多くの場合、ソフトウェアをリファクタリングして内部構造を改善するよりも、抽象化のレイヤーを追加する方が簡単です.(https://de.wikipedia.org/wiki/Anti-Pattern)
    • スイス アーミー ナイフ (別名キッチン シンク):One-Tool Wonder は、あらゆるニーズに対応する普遍的なソリューションです。万能薬 (AntiPatterns から)。このアンチパターンは、ゴールデン ハンマー シンドロームと強く関連しています。
    • ゴールデン ハンマー :(別名 head-in-the-sand) ゴールデン ハンマーは、多くのソフトウェアの問題に強迫的に適用されるおなじみのテクノロジまたは概念です (AntiPatterns から) 代替戦略の知識の欠如が主な理由です。また、以前のソリューションは非常にうまく機能し、もう一度適用されます。

    ソフトウェア アーキテクチャのアンチパターン

    • 神の階級 (ブロブ):「神のクラス」は、システム内のあまりにも多くの他のオブジェクトを制御するオブジェクトであり、すべてのロジックを超えて成長し、すべてを行うクラスになります。 (https://wiki.c2.com/?GodClass)。多くの場合、設計を分解するよりも、メンバー関数をクラスに追加する方が簡単です。
    • スパゲティ コード: スパゲッティ コードは、構造化されておらず保守が難しいソース コードに対する軽蔑的な言葉です。 (https://en.wikipedia.org/wiki/Spaghetti_code)。明らかな理由は GOTO の使いすぎです ステートメント、例外処理、または深くネストされた if-else 構造。抽象化の欠如とアーキテクチャの分解が主な原因です。
    • 大きな泥の玉 :知覚可能なアーキテクチャを欠くソフトウェア システム (https://en.wikipedia.org/wiki/Big_ball_of_mud)。典型的な理由は、時間と機能を重視した設計です。

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

    • ブルックの法則 :遅れているソフトウェア プロジェクトに人員を追加すると、遅くなります。 (https://en.wikipedia.org/wiki/Brooks%27s_law)。新人は経験豊富な開発者によるトレーニングを受ける必要があるため、開発プロセスが遅くなります。
    • 死の行進 :参加者が失敗する運命にある、または持続不可能な過重労働を必要とするプロジェクト (https://en.wikipedia.org/wiki/Death_march_(project_management)。会社の文化は管理に基づいていますが、信頼には基づいていません。反対意見
    • きのこの管理 ：「彼らを暗闇に閉じ込めて、たわごとでいっぱいにさせてください。」一部のアーキテクチャおよび管理サークルでは、システム開発者をシステムのエンド ユーザーから隔離するための明確なポリシーがあります (AntiPatterns から)。会社の文化は制御に基づいていますが、信頼には基づいていません。

    次は?

    次回の投稿では、古典的なデザイン パターンについて書きます。まず、作成パターンについて書きます


    No