妄信

開発パッケージを評価する時に良く見るのだが、誇大な宣伝文句を一方的に信じてはいけない。

• プログラミングを否定している

「SEだけでシステム開発が出来ます」とか「難しいオブジェクト指向を理解する必要はありません」なんてのは嘘。

属人性の高いプログラミングをできるだけ排除することにより会社上層への受けは良くなるんだろうが、いろいろな人が書いたプログラムにより構成されている癖にプログラミングすることを悪としてできるだけ排除するのにデメリットはあってもメリットは無いように思う。
このようなパッケージはとにかくコードの自動生成をしたがるが、DTOのようにレイヤ間で発生するデータの詰め替え処理や発生するイベント処理のように、書くと単調になるコードを自動生成するのは良いアイディアだと思うが、業務用パッケージではないのだからそれ以上の無茶なコード生成は一理も無い。

• コアアーキテクチャ(フレームワーク)を隠蔽している

「strutsを隠蔽しメリットだけを最大限に生かします」とか、「面倒なJ2EEのための記述は不要です」なんて謳い文句を見たら警戒したほうが良い。

strutsを拡張して独自フレームワークとして提供している例は非常に多く見る。そのようなパッケージはstrutsをベースにしたプレゼンテーション層を構成しているのだが、strutsを拡張して使っているのにも関わらず実装では必死でStrutsを隠蔽しているところが気に食わない。ましてや堂々とstrutsのメリットまで書いているのであればstrutsとして普通に使えるようにしておくのが当たり前であって、例えばstrutsの設定ファイルはツールにより自動的に生成したものを使います、というのは便利でもなんでもないだろう。
同じように、J2EE準拠を歌っておきながらJ2EEのDeployment Descriptorを隠蔽して任意に編集できない作りになっていたりするのは最悪だ。

• 特定の開発環境にロックインしている

「デファクトスタンダードであるXXXXをサポート」とか「GUIによる簡単な操作で業務ロジックの基本部分を生成できます」などということが書いてあったら、新たなGUIや生産性の悪いエディタを使わされる可能性がある。

例えばEclipseのプラグインで作った簡易なエディタをツールとしてプレゼンテーションレイヤのトランスミッション制御やOO、ORマッピングをを記述しており、それがアプリケーションを開発する際の縛りになっているのは便利そうだがあまり良くない。Eclipseはシェアも高いし問題無いかもしれないがそれならば他のプリミティブな手段も用意すべきだ。
また、特定のサーバや特定のアプリケーションサーバでしか動作できない(させない)のは最悪。

• ドキュメントとソースコードが依存関係にある

「ドキュメントとソースコードの不整合が無くなります」とか「仕様書から業務ロジックを直接導き出せます」と書かれていたら仕様変更がやり難いかもしれない。

特定のツールで書かれた設計書から出力されるデータを入力として、業務ロジックの雛形を自動生成するようツールが用意されていたりすることが多いが、自らが行うコーディング量を少なくすることを第一義にしてしまい、ソースコードだけを修正することが出来なくなってしまっているツールが多い。これは開発者にとっては手戻りの際に地獄となる典型的な開発パッケージのアンチパターンなのだが、こういう構成でがちがちにしているケースが多い。