Chapter 03

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

たなかなた
たなかなた
2022.12.12に更新
このチャプターの目次
  1. おんぼろ煙突化（Autogenerated Stovepipe）
  2. 全社的おんぼろ煙突化（Stovepipe Enterprise）
  3. システムのおんぼろ煙突化（Stovepipe System）
  4. 平直混在（Jumble）
  5. 総花主義（Cover Your Assets）
  6. 砂上の楼閣（Venter Lock-In）
  7. 羊頭狗肉（Wolf Ticket）
  8. 文書化軽視（Architecture by Implication）
  9. 無能集団化（Warm Bodies）
  10. 組織硬直（Design by Committee）
  11. 万能ナイフ（Swiss Army Knife）
  12. 自作固執（Reinvent the Wheel）
  13. 実装溺愛（Grand Old Duke of York）
  14. 象牙の塔アーキテクト
  15. 汎用アーキテクチャ
  16. 巨大な泥団子
  17. 暗黙のアーキテクチャ
  18. 偶発的アーキテクチャ
  19. アーキテクチャシンクホール
  20. アーティファクトへの不合理な愛着

おんぼろ煙突化（Autogenerated Stovepipe）

全社的おんぼろ煙突化（Stovepipe Enterprise）

  • 発生
    • 企業の複数のシステム間において、ソフトウェアの再利用性や相互運用性がなく、一枚岩的なアーキテクチャとなっている
  • 回避
    • 以下を明確にし、相互運用性の課題解決と技術調整を行う
      • ４つの要件モデル
        • オープンシステムの基本形
        • 技術プロファイル
        • オペレーティング環境
        • システム要件プロファイル
      • ４つの仕様モデル
        • 全社的アーキテクチャ
        • 計算施設アーキテクチャ
        • 相互運用性仕様
        • 開発プロファイル
  • 参考文献

システムのおんぼろ煙突化（Stovepipe System）

  • 発生
    • 単一システムにおいて抽象化が欠如していてサブシステム間調整ができておらず密結合
    • サブシステムを統合するためのインフラが多岐に渡っており、共通の機構が存在しない
  • 回避
    • コンポーネントベースのアーキテクチャを導入する
  • 参考文献

平直混在（Jumble）

  • 発生
    • 以下２つが入り混じっている
      • 垂直的設計要素：個々のアプリケーションとソフトウェアに依存する設計要素
      • 水平的設計要素：複数のアプリケーションに共通する一般的な設計要素
  • 回避
    • 水平的設計要素をまとめて抽象化して別アーキテクチャ層に移し、垂直的設計要素の特殊な機能性や性能要件などの実装する
  • 参考文献

総花主義（Cover Your Assets）

  • 発生
    • 重要な意思決定を避けて安全第一主義の立場を取るせいで、あらゆる代替項を並列的に網羅した焦点が定まらずに役立たない文書を作成する
  • 回避
    • アーキテクチャのプループリント（概要説明書）を作成する（1ダースを超えない図表で構成され、1時間程度でプレゼン可能なブループリントを心がける）
  • 参考文献

砂上の楼閣（Venter Lock-In）

  • 発生
    • ある一つの製品技術を採用し、やがてそのベンダの実装に依存した状態になり、アップグレードのたびに変更が生じたり、逆にアップデートされないせいで必要な機能を盛り込めなくなる
  • 回避
    • 既存のソフトウェアとベンダのソフトウェアの間に隔離層を設ける
  • 参考文献

羊頭狗肉（Wolf Ticket）

  • 発生
    • オープンであるとか標準規格に準じているなどと称しながら実態を伴っていない
  • 回避
    • 草の根活動により技術のギャップ（仕様、企画準拠度、相互運用性、堅牢性など）を埋める
  • 参考文献

文書化軽視（Architecture by Implication）

  • 発生
    • 以前に同様のシステム構築を行った事のある自信過剰なアーキテクトやデベロッパが、文書は不要と考えている
  • 回避
    • 複数のステークホルダの視野を活用し、各ステークホルダにおいて重要な文書を定義する（この活動を組織として行う）
  • 参考文献

無能集団化（Warm Bodies）

  • 発生
    • プログラマのうち20人に1人が平均的なプログラマの20倍のプログラムを生産しており、その他は頭数要員のために招集された集団になっている
  • 回避
    • プロジェクトの理想的なサイズは4人のプログラマで、理想的な期間は4ヶ月
  • 参考文献

組織硬直（Design by Committee）

  • 発生
    • 全員に平等な発言権を与える事によって、抽象はピンボケになり、過剰な複雑性を有無
    • 船頭多くして船山に上るし、料理人が多すぎるとスープが台無しになる
  • 回避
    • 不毛な会議体を除外し、意味ある会議体だけを生かす
  • 参考文献

万能ナイフ（Swiss Army Knife）

  • 発生
    • あらゆるニーズを満たすため、一つのクラスに大量のインターフェースのシグネチャを盛り込み、異様に複雑なクラスと使わないといけない
  • 回避
    • 万能ナイフを使わないといけないので、利用規約を定めたプロファイルを作成する
  • 参考文献

自作固執（Reinvent the Wheel）

  • 発生
    • 車輪の再発明。単一のシステムを周りと無関係に孤立的に開発する（処女システム仮説）。
  • 回避
    • ”アーキテクチャの耕作(farming)”ではなく、”アーキテクチャの採掘(mining)”を行う（新たに考えるのではなく、前例を探して適用する）
  • 参考文献

実装溺愛（Grand Old Duke of York）

  • 発生
    • 画家が「抽象画」「具象画」に分けられるように、プログラマは「抽象派」「実装派」に分けられる
  • 回避
    • 役割分担を行い、アーキテクトには「抽象派」と、デベロッパには「具象派」を演じさせる
  • 参考文献

象牙の塔アーキテクト

  • 発生
    • 開発チームの意見や懸念を無視して、上から目線で何をすべきかを指示しているだけのアーキテクト
  • 回避
    • 開発チームとコミュニケーションを取り、協働してアーキテクチャ決定を下す
  • 参考文献

汎用アーキテクチャ

  • 発生
    • すべてのアーキテクチャ特性をサポートしようとして、システム全体が複雑になる
  • 回避
    • 設計をシンプルに保つ。最も重要な特性３つを顧客に決めてもらう。
  • 参考文献

巨大な泥団子

  • 発生
    • 認識できるアーキテクチャ構造が不在の状態。循環依存状態であったり、スパゲッティ状態であったり、パッチワーク状態であったり、とにかく悲惨。
  • 回避
    • リファクタリング
  • 参考文献

暗黙のアーキテクチャ

  • 発生
    • コンウェイの法則が働く組織において、暗黙的に形成されるアーキテクチャ。(シンプルさや親しみやすさはある)
  • 回避
    • 他のアーキテクチャスタイルを学び、適切なスタイルを適応する
  • 参考文献

偶発的アーキテクチャ

  • 発生
    • コンウェイの法則が働く組織において、偶発的に形成されるアーキテクチャ。(シンプルさや親しみやすさはある)
  • 回避
    • 他のアーキテクチャスタイルを学び、適切なスタイルを適応する
  • 参考文献

アーキテクチャシンクホール

  • 発生
    • 「レイヤードアーキテクチャ」において、各レイヤー内でビジネスロジックが実行されず、リクエストがパススルーされてレイヤー間を移動してしまう
  • 回避
    • 80対20ルールに従う。すべてのレイヤーを開放レイヤーにする。
  • 参考文献

アーティファクトへの不合理な愛着