尚、★印は５段階に分類した要注意の度合いで、発生頻度×影響度って感じ（感覚ベースの脳内統計だが･･･）。
- ■ Spaghetti Code ★★★★★
BPEL の言語的性質から、実行パスがもつれたり絡んだりする事はそれほど無くて、古典的な意味でのスパゲティにはならないが、グローバル変数がらみの広義のスパゲティになる事が多い。
グローバル・スコープに変数を定義して、複数のアクティビティで上書きしながらワーク領域として使いまわしているコードがあったりすると、可読性が落ちるわ潜在バグの温床になるわで、生産性と品質の両面に大きなダメージがある。
- ■ The Blob ★★★★
- オリジナルは、与えられた責務が多すぎてオブジェクトが肥大化している状態を言うが、BPEL でもプロセスが長すぎて困るのは良くある。
長いからその分いろんな改修や仕様変更の影響を受けやすく、複数担当者で作業対象がカブる率が高くなり、生産性にかなり悪影響がある（担当者のアサインの仕方にもよるが）。
改善のためには BPELコーディングの面よりも、主にプロセス設計の面からのアプローチが有効と考えられる。例えば、プロセスを分割するとか、サブプロセスとして別サービスに括りだすとか。 - ■ Functional Decomposition ★★★★
- オリジナル AntiPatterns では、オブジェクト指向開発なのに非オブジェクト指向で書かれたコード、例えばポリモーフィズムを使うべきところで if文や switch文を使っているなどの悪習を指す。
言語の本来の性質や目的に合っていないコーディングという意味では、BPEL の場合だとサービスのオーケストレーションに寄与していないコードが怪しい。例えば<assign> しか含まないループや分岐は、BPEL ではなく XSLT で書くべきケースが多い（書き易さの面でも）。 - ■ Cut-and-Paste_Programming ★★★★
- BPEL でも重複コードは頻出で、やはり大体コピペで作られる。ただし BPEL 自体、小さなサブルーチンに細かく分割するのに向いてる言語ではないため、普通のALGOL系言語より重複しやすい。
そういった仕方の無い面もあるにせよ、やはり度が過ぎると、たった一つの変更が何十個所もの改修に及んだりしてダメージが大きいため、できるものなら解消したい。
やり方は、xpath 関数を拡張するとか、XSLT に切り出して再利用するとか、プロセスの一部を別サービスに切り出すなど。いずれのやり方も自明でも無いし常に適用可能でもないので、工夫と妥協が必要。 - ■ Input Kludge ★★★★
- 都合の良い入力条件でしかまともに動かないプログラムを指したアンチパターン。
オブジェクト指向開発だと xUnit や TDD が高度に発達して、既にかなり普及しているけど、それらのノウハウを BPEL に適用するのは現状ではなかなか難しい。入出力XMLデータの検証くらいは簡単にできるけど、途中の Web サービスとのやり取りまで含む検証は、意外と手間がかかるしシナリオの想定も難しい。
あと厳密に Input Kludge に該当するか分からないが、開発環境で本物の Webサービスの代わりに使うスタブでも同様の問題が生じる。スタブ化しようとするサービスのドキュメントの不備や解釈のブレによって、なかなか実物のサービスと開発者の想定が一致しない。で、スタブでは動いたが実サービスを繋いだテストでは不具合が出るということになる。
プロジェクトの性質によって対処法はまちまちだろうけど、なるべく早いフェーズでテストと実装（特にスタブ）の戦略は立てておく必要がある。
- ■ Lava Flow ★★★
- 使われなくなったコードのことで、デッドコードとも言われる。仕様変更の対応などに伴って BPEL でもよく発生する。あるBPELプロセスの全体、またはその部分、或いはBPELから使用している*.xslファイルや*.xsdファイルなどが、いつの間にか使われなくなったりする。
これについても、無駄なメンテナンスが発生するので、なるべく早く削除すべき。（ちなみにコメントアウトして残す癖のある人もいるが、良い習慣ではない。） - ■ Golden Hammer ★★★
- オリジナル AntiPatterns では、ある特定の解法や技術を何にでも盲目的に適用してしまう事を指す。ややキツ過ぎる言い方になるが、日本語だと「バカの一つ覚え」ってところだろうか。
BPEL 開発でも、知識が足りないまま作業開始して手探りで進めているようなプロジェクトで、頻繁に生じる。過去に見かけて印象に残った例だと、BPEL外部の XMLファイルの内容にアクセスするために、標準 xpath 関数のdocument() を使えばいい事を知らずに、無理やり orcl:lookup-xml()を使っていたコードなどがあった。 - ■ Ambiguous Viewpoint ★★★
- 分析の視点と実装の視点の混同、特に分析・設計時に実装の問題を混入させてしまう事を指す。
BPELの場合、OO言語を用いた開発に比べて、実装に先立つ設計作業の比重が大きかったりするが、ここでワーク変数の扱いだとかデータ加工の具体的ロジックなどまで含めてしまうのは、本当に百害あって一利なしなのでやめるべき。
- ■ Continuous Obsolescence ★★
- 準拠する仕様や基盤となる製品のバージョンアップにともなって、既存コードが絶え間なく陳腐化していく現象を指す。BPEL開発 の場合、まず BPEL、XSLT、XPATHといった標準仕様、またそれらについて各製品独自に拡張した部分、さらに 基盤となる BPEL／SOA 製品などについて、各々、時間の進行に伴ってバージョンが上がって行く事になる。
まあ、そもそも疎結合が SOA の謳い文句なので、外部サービスのバージョンアップの影響は余り受けずに済む。サポート期限などは別にして、陳腐化についてはそれほど神経質にならなくてもいいかも。
尚、開発を始める段階でなるべく新鮮は最新版の製品を使えば、陳腐化までの時間を長引かせる事はにはなるが、下記の Walk through a Minefield には注意する必要がある。 - ■ Walk through a Minefield ★★
- リリース後間も無い未知のバグを含む新製品を採用して、問題解決に困ってしまうというアンチパターン。
これは発生頻度もダメージも、プロジェクトや製品ごとにまちまち。対策としては、プロトタイピングとか、反復型プロセスで早期に問題を燻り出したりとか、まあ普通のリスク回避策しかないか。開発に取り掛かった時点で「枯れている」製品を選ぶのも一つの手だが、これも気をつけないと陳腐化リスクが大きくなる。 - ■ Poltergeists ★★
- 存在意義があまりないクラス。
BPEL の場合だと、例えばサービスを一個呼ぶだけのプロセスなど単にコンポジットから呼び出せば済むような、オーケストレーションが無いプロセスはこれに当たると考えられそう。 - ■ Mushroom Management ★★
- エンドユーザから隔離されたデベロッパが、十分な要件定義も与えられないまま、想像でコーディングするしか無い状況に追い込まれること。まあ BPELに限らずシステム開発プロジェクトの初歩的な問題なので割愛。
- ■ Boat Anchor ★
- 現在の開発対象システムには不要と思われる贅沢な機能を満載したソフトやハード。
単にお金が掛かるというだけなら、自分の金じゃないし払う方の勝手だけど、そのために本当に必要なリソースが圧迫されるとしたら、PM かステークホルダに具申する必要がある。
また OSS の軽量な製品で事足りるのに、重すぎて扱いにくい商用製品が使われてたりすることもよくある。開発端末ではありえないレベルの高スペック・サーバマシンじゃないと動作しないような BPEL 製品だとか、そういうのは本当に生産性が落ちるから、極力避けたい。 - ■ Dead End ★
- 他所から入手した再利用コンポーネントを部分変更した後、サポートを受けられなくなってしまうこと。
まあ、あまり起こりそうに無いし、気にしなくてもいいか。
0 件のコメント:
コメントを投稿