アンチパターン

ある問題に対する、不適切な解決策

「こうあるべきだ」という典型例を集めたものがデザインパターン。

こうあってはならない」という典型例を集めたテンプレート集がアンチパターン。

http://thinkit.co.jp/article/929/1

ソフトウエア開発は、失敗が日常化し、その結果として、開発に携わる技術者は大変な苦労を重ねる。

１．特定のクラスのみが肥大化していく、“Blob”（人喰いアメーバ）

・単一のクラスに大量の属性やメソッドが集中している

・単一のクラスにお互いに関係のない属性やメソッドが混在している

・単一のコントロールクラスに単純なデータオブジェクトが結びついている

対策

・要求仕様に基づいて、属性とメソッドを関連するもの同士で分類し、グループ化する

・分類した属性、メソッドを、新たなクラスに移すことを検討する

・クラス間の結びつきを見直す

・本来固有でないメソッド（汎用ユーティリティー的な性格のメソッド）などを別のクラス（ユーティリティークラス）に移す

既存のプログラムコードを切り張りして安易な流用を繰り返す

Cut-and-Pasteプログラミング

・バグフィックスをいくら行っても、同じようなバグがあちこちで発生する

・全体的な生産性が向上しないにも関わらず、プログラムコードの行数が増加する

・コードの品質検証に手間がかかる

対策

将来の機能拡張のことを考慮したソフトウエアの設計

共通するふるまいの部分をうまくカプセル化し、拡張部分を追加していけるような設計

重複したコードは、地道なリファクタリングによって整理

今となっては必要でない、プログラムコードの残がいのことを“溶岩流”Lava Flow

・その場しのぎ的な変数やコードが次から次へと追加されている

・ドキュメントなどの説明がないコードが多数存在している

・使われていないデッドコードが多数存在している

対策

・場当たり的な開発でなく、きちんとしたアーキテクチャに基づく開発

・溶岩流となったコードを地道に除去するくらいなら、1から作り直した方が効率が良い場合もある

スパゲッティコード

・再利用できそうなオブジェクトやメソッドが少ししかない

・メソッドの中に大量のロジックが記述されている

・オブジェクト間での呼び出し関係がほとんどない

・オブジェクトのメソッドにパラメータがなく、インスタンス変数やグローバル変数を直接操作している

・オブジェクトの使い方がワンパターン

ストーブパイプアンチパターン

・アーキテクチャの設計文書と実際に構築・実装したシステムとの間に大きな隔たりがある

・アーキテクトが統合化技術について知識がなく、経験もない

・システムの要件変更を行うと、とんでもない費用が発生する

・サブシステム間で新しいインターフェースを追加するのに大変な調整が必要になる

対策

Webサービス（SOAP、WSDL）など、相互運用性が高く、特定のプログラム言語に依存しない技術を用いる

Stovepipe Enterprise（ストーブパイプエンタープライズ）

・全社的な技術戦略が欠如している

・システムのデベロッパー間で協力関係がない

・システム開発プロジェクト間でコミュニケーションがない

・社内の技術の標準化について議論がない

対策

企業全体としての、技術の標準化や、全社レベルでのアーキテクチャの整理が必要

Vendor Lock-In（ベンダーロックイン）

・ベンダー製品のアップグレード時には、アプリケーションのメンテナンスを行う必要性が高い

・ベンダー製品側の機能リリースが遅れたりするとアプリケーション開発に大きな影響が生じる

・ほかのベンダーと相互互換性のない製品を使っている

対策

OSへの依存性を低くしたいのであれば、アプリケーションをJava VMなどの仮想マシン上で稼働させる

ミドルウエアのAPIなどに依存性を低くしたいのであれば、SpringやS2などのフレームワークを用いる

Design by Committee（委員会設計）

・設計文書が複雑である反面、一貫性に欠ける

・設計文書に欠陥が多い

・設計文書が異様に分厚い

・多数の人が設計の会議に参加しているが、議論が散漫で一向に進展しない

・会議をしないと何事も決まらなくなっている

対策

・会議のやり方を変える

・会議の目的を明確にして時間内に効率よく物事を決定する運営に変える

・プロジェクト組織の見直しを行う

・システム全体のアーキテクチャを決定するアーキテクトは誰か、役割分担を明確にすることが重要

Reinvent the Wheel（車輪の再発明）

・アーキテクチャとソフトウエアがシステムごとに検討され、複数のシステム間での相互運用性や再利用は検討されない

・市販のライブラリやミドルウエアを用いれば良い機能まで内製する

・1から作るため、アーキテクチャと要求仕様書などの完成度が低い

対策

・過去に作られた設計情報を生かす

・古い設計情報には陳腐化したものもありますが、過去のプロジェクトにおいて実用的なシステムを構築するための知恵もたくさんつまっている

・アーキテクチャ・マイニング（architecture mining）

過去の設計情報から、新しいシステムを構築するために有用な情報を集めること

Architecture by Implication（含蓄アーキテクチャ）

・アーキテクチャ計画と仕様書が存在しない

・アーキテクチャに関する潜在的なリスク（スケーラビリティ、ドメイン知識など）がプロジェクトが進行するにつれ顕在化してくる

・場当たり的なアーキテクチャであり、性能の不足、アーキテクチャのシンプルさ、ユーザーの使い勝手などが十分に考慮されず、こうしたリスクがプロジェクトの失敗につながる

・アーキテクトの勘と経験に頼るため、新技術が無視される（もしくは安易に新技術を採用する）

対策

・ソフトウエアアーキテクチャ

・ハードウエアアーキテクチャ

・ネットワークアーキテクチャ

・永続化（データベース）アーキテクチャ

・セキュリティーアーキテクチャ

・システム管理アーキテクチャ ……などなど

これらについて、それぞれの目的・目標を明確にし、

関係者の意見を調整するために、アーキテクチャの設計資料を作成し、

情報を共有化する必要がある

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

本来は、ソフトウエア開発者はITの進化を支える花形職業であるはずなのですが、開発の現場ではデスマーチ・プロジェクトが常態化した結果、3K（きつい、厳しい、帰れない）職場と揶揄（やゆ）され、学生の人気も今ひとつ

Analysis Paralysis（アナリシス・パラリシス）

・プロジェクトの方向転換や分析モデルの作り直しが頻繁に発生する

・設計と実装の話が分析の段階において入り込む

・分析がユーザーとの対話抜きで進められている

・分析モデルが複雑になっている

対策

実際にプログラミングやテストを行う前に、

完全な仕様の分析や設計を終わらせることに固執し、

分析が完ぺきだと安心できるまで先に進めなくなってしまうから

プログラミングやテストを実施した結果をフィードバックしながら、仕様を改善していく

Death by Planning（デス・バイ・プランニング）

・計画に実現性があるとは誰も思っていない

・納期よりもコストを気にする

・プロジェクトの予算を握っている人が、プロジェクト計画の細部に口出しをする

対策

何をいつまでにリリースするのかを明確にした基本計画を作成することが大事

無理のない、基本計画があれば、計画の詳細化は必要な段階で実施する

最初は大まかに見積もっておいて、詳細部分が明確になった時点で計画を詳細化する

Project Mismanagement（プロジェクト・ミスマネジメント）

・アーキテクチャが確立されていないため、テストの段階で技術的な問題が数多く発生する

・プログラムコードのレビューがたまにしか行われない

・プロジェクトの終盤になっても、ソフトウエアの品質が向上しない

対策

アーキテクチャの要件（機能、性能、信頼性、操作性、セキュリティーなど）を明確化し、設計・コーディング・テストを通してアーキテクチャの検証・確立をきちんと行う

Irrational Management（イラショナル・マネジメント）

・重要な課題について議論ばかりされていて結論が出ない

・プロジェクトメンバーのフラストレーションがたまる一方である

・納期がどんどんと伸びていく

対策

プロジェクトマネジャー自身が1人相撲を取らずに、役割分担を見直すことが必要

技術的事項の決定はアーキテクトにゆだねる

プロジェクトマネジャー自身はマネジメントに専念

プロジェクトの目的・目標の共有化や、プロジェクトメンバーとのコミュニケーションも重要