アンチパターン
ソフトウェア危篤患者の救出
書誌
| text | 唯野 |
| author | William J. Brown, Raphael C. Malveau,Hays W."Skip" McCormick III, Thomas J. Mowbray |
| editor | 岩谷宏(訳) |
| publisher | ソフトバンク |
| year | 1999 |
| price | 2,400+tax |
| isbn | 7973-0758-7 |
履歴
| 2002.2 | 読了 |
| 2002.3.14 | 公開 |
| 2002.11.28 | 修正 |
感想
書名から察しがつくのかもしれないが、デザインパターンを意識して考えられた「ソフトウェア開発においてネガティブな結果を招くパターン集」の本。実をいうと私はまだデザインパターン本体の方をちゃんと理解するには至っておらず(GoF 本もななめ読みレベルである)、そういう意味では読む順序を間違えているともいえる。しかし、GoF 本より後に登場しているだけあって、GoF 本を越えるための試みもいくつかある。例えば、これは私も感じた欠点のひとつだが「長い説明の後で実は結論があまりにもあっけなくて拍子抜けした」というものがある。「それならばもっと分かりやすい結論を先に書いてくれ」というところだが、本書の場合、訳者によるあまりこの手の技術書では見かけないような訳語と相まって、そのような点での読みにくさはかなり軽減されているように思う。(まあ、逆にこの訳語が嫌だという人もいそうな気はしますが。)
本書の著者はいずれも OOP のエキスパートで CORBA 関連の著作があり、それゆえ OOP の知識は前提、その上で IDL や IIOP、オープングループという(CORBA 絡みのキーワードを用いた)優位性に絡めた説明が割と多い。そのせいで、ごくたまに相応の予備知識がないと理解できない箇所がある。つまり、個々のパターンを読むだけであれば特に問題はないが、割と上級書に近い感じがありバランス面ではいまいちということだ。とはいえ、物事に対するネガティブ面に立ったアプローチは非常にうまいと思うし、個々のパターンもうなずけるものが多いので、個人的に敬遠するよりは一読に値する本だと思う。
抄録
xvi/xvii/xxiv/10/17/20
やってはいけないこと、このままではやりそうなこと(否定的なパターン)に早期に気付くことの重要性。ソフトウェアの失敗が普遍的なのは実践されているデザインパターンよりもアンチパターンの方が圧倒的に多いためである。それゆえアンチパターンを問題の検知(問題のある解法)と解決策(再構想(refactoring)による解法)とでセットにして提示する。デザインパターンも解決する問題より生起する問題の方が多ければアンチパターンであり、つまりパターンが良好かどうかは状況に依存する。アンチパターンは組織全体のレベルを視野として捉えられなければならない。ここではそれらを以下の 3 つに分類する。cf.9
- 開発の次元のアンチパターン
- アーキテクチャの次元のアンチパターン
- 管理の次元のアンチパターン
7
――ベンダは、彼らのソフトウェアが現実に何かの役に立つ、と保障することは滅多にない。何かまずい動作をしても、それは彼らの落度ではないと主張される。私企業的な(proprietary)技術は、4 か月から 1 年半ぐらいのサイクルでころころと変わる。急速な技術変化がソフトウェアのメンテナンス費用を慢性的に支配し、開発/導入の足を引っ張る。顧客がソフトウェアのライセンスを購入したら、ベンダはその同じ顧客から当初のライセンス料の 4 倍の金を巻き上げることを期待している――-/-
11/13/15
デザインパターンそのものは 1970 年代に Christopher Alexander という建築家が建造物をパターンとして提供したことに端を発する。これをコンピュータの世界へ初めて応用したのが Ward Cunningham と Kent Beck で 1987 年のことだが、実際にそれがオブジェクト指向の世界で市民権を得たのは 1994 年のパターンに関する初の会議(Pattern Language for Program Design : PLoP)以降である。しかし、それは同時に何にでもデザインパターンを適用しようとするデベロッパの存在も生み出した。
19
デザインパターンが他のソフトウェア手法と異なるのはテンプレートを使う部分にある。テンプレートとはパターンの構成情報を一定形式として文書化したもので、全てのパターンはこの共通したテンプレートとして記述される。
23-43/45-59
アンチパターンの基盤として以下の要素が挙げられる。
- 根本原因(root cause) 根本状況
- 中心圧力(primal forces) 中心的な動機
- ソフトウェアデザインの対象レベルの各段階(Software Design-Level Model : SDLM) 対象するレベルとスケール
そして、根本原因として以下の要素がある。
- 拙速(Haste) 構想不足による品質の低下
- 無関心(Apathy) 解決方法の無視と分割の欠如
- 狭量(Narrow mindness) 実用的な解法の拒絶
- 不精(Sloth) 意思決定の安易さによる制御不可状態
- 強欲(Avarice) 過剰な複雑性によるコスト増大
- 無知(Ignorance) 理解努力の放棄と実装依存
- 高慢(Pride) 車輪の再発明へのこだわり
また、リスクとは何らかの圧力の現れであり、圧力は意思決定を左右する懸案事項・課題を指す。その上で圧力と中心圧力として、それぞれ以下の要素がある。
- 垂直圧力(ドメインに固有の圧力、状況が特定的)
- 水平圧力(複数のドメインに共通する圧力、間接的な圧力)
- 中心圧力(あらゆる部分に存在する水平圧力)
- 機能性の管理 ユーザ要求の実現管理、相互運用性によるモジュールの協働
- 実行性能の管理 ニーズの変化に対応できる透過性、最適化
- 複雑性の管理 良質な抽象化の維持のための問題の早期発見
- 変化の管理 インタフェースなどの独立性、ポータビリティ
- IT 資源の管理 企業における資産管理
- 技術移転の管理 情報交換の範囲、標準規格形成への影響
更に中心圧力の影響範囲を職能とシステムの規模から捉えると以下のようになる。これらは、視野の分割による個々の選択のスコープの限定、優先順位設定による選択への明快な指針とリスク管理という部分で意味を持つ。
| 中心圧力の影響範囲 | 業界全体 | 企業 | システム | アプリケーション |
| 機能性の管理(設計家、デベロッパ) | 非重要 | 周辺的 | 重要 | 最重要 |
| 実行性能の管理(設計家、デベロッパ) | 重要 | 重要 | 最重要 | 最重要 |
| 複雑性の管理(PM、設計家) | 重要 | 最重要 | 重要 | 周辺的 |
| 変化の管理(PM、設計家、デベロッパ) | 非重要 | 最重要 | 最重要 | 重要 |
| IT 資源の管理(CIO、デベロッパ) | 非重要 | 最重要 | 重要 | 周辺的 |
| 技術移転の管理(CIO) | 最重要 | 重要 | 重要 | 周辺的 |
なお、SDLM の個々の要素として以下があり、これは下に行くほど裾野が広い。
- オブジェクトのレベル 再利用性のためのクラス開発、シグネチャ
- マイクロコンポーネントのレベル 自己完結した類似のソフトウェア問題
- マクロコンポーネントのレベル フレームワーク(コンテナ・クラス階層)の編成と開発
- アプリケーションのレベル ユーザ要件を満たすための実装(GUI、ラッピング)
- システムのレベル 複数アプリケーション間による相互運用(水平・垂直インタフェース、メタデータ)
- 企業のレベル 単一組織内における中心課題(インフラ、ポリシー)
- 業界全体のレベル あらゆるシステムに普遍的な設計課題(標準規格)
最後に全域(業界全体)レベルの標準規格として以下がある。
- 公的規格(formal standards) ISO、ANSI、IEEE などが策定した標準規格
- デジューリスタンダード(de jure standards) 政府機関の認定した規格
- デファクトスタンダード(de facto standards) 広く使われている立場によるもの
- コンソーシアム規格(consortium standards) OMG、Open Group など
本書では登場するパターン全体を上記のカテゴライズされた中での位置としても説明している。が、私には個々のパターンが持つ最大の特徴にしか関心がないので、その辺は扱わず、上記に関してはそれらの基準だけを列挙した。というのも、パターンというもの自体、その全ての把握というよりはまず概要を一通り押さえておいて、後は必要なら詳細を見るというような使われ方をイメージしているように考えているためである。言い換えると、そういう安易な使い方もできないとパターンとはいえないということだ。(唯野)
全文を読まれる場合はログインしてください
Up