作らない開発というよりGeneXusそのものの話。
ツール(IDE)の使い方やオブジェクトの作り方についてはよく説明されていますが、割とおざなり
にされるのが、GeneXusらしい設計の仕方の話です。
項目名はKB内で唯一無二であり、オブジェクト指向でいう所のオブジェクト名やテーブル名
などでは修飾されない、という話は有名です。しかし、よく考えるとその話は最初だけに
出てきて、実際使い始めたら「そうしなければ使えない」から仕方なく唯一無二にしている、
ような感が満載のKBをしばしば見かけます。
具体的には、どう考えても同じ意味の項目にテーブル名を含めた項目名を付け、テーブル
ごとに別物扱いにしているケースです。
理由を尋ねると、往々にしてDB設計が最初に手動でなされていて、それに合わせてGXで
開発しようとしらそうするしかなかった、というような話が出てきます。
開発者がGXに不慣れで、そうしてしまったとかならまだこれから改善する可能性は高いの
ですが、厄介なのは「体制がそうなっているから」とか「開発方法論がそうなっているから」
というケース。
どちらも同じようなものですが、体制というのはDB設計とプログラム開発が空間的に
分かれている場合で、開発方法論というのは両者が時間的に分かれている場合、といえば
イメージがつくでしょうか。実際はその併用が多いかもしれません。
項目名が唯一無二、という本当の意味は、唯一無二であることによってデータベースの
どこでその項目が管理されるかが決定され、また唯一無二であることによってその「どこ」
が移動してもかまわない、ということです。
したがって「構造」は項目名によって自由自在に変わるし、変えることができるのです。
とにかく技術者は戻ることを極端に嫌うので、空間的時間的に分かれている場面で
「項目名を、ひいては構造を変えてくれ」なんて言い出そうものならパニックになることは
想像に難くないですし、プログラム開発者、この場合はGX開発者もそれがわかっているので
何も言いださない。これは以前出てきたプロジェクトNの開発者Aのエピソードが典型例です。
また、こうした問題はかくいう私が開発者だったときも発生しているため、開発者の堅い
意志に依存して解決できるものでもないのです。
それこそ体制と開発方法論の問題なので、GXを導入すると検討・決定する段階から、
プロジェクトリーダーやオーナーが決めていかなければなりません。
一方で、テーブルごとにばらばらになった項目はどう扱われるのか？
今まで見たことのあるKBでは、本当にVBのような従来開発手法で作られており、
あらゆるプロシージャにwhere条件でテーブル同士を結合させ、場合によってはSDTに格納、
ウェブパネルで表示編集を行っていました。
まあ、それをやっていたら「SQLを直接書けない」であるとか「画面のパフォーマンスが遅い」
とか、GXへの不満が出てくるのもさもありなんですわな。
問題はもっと別のところにあるのです。