今まで散々「作らない開発」「作らない開発」と連発していましたが、GeneXus的な作らない
開発を一言で言えば、以前の記事のタイトルにある「構造で解決」で終わってしまいます。
では、なぜ構造で解決すると作らなくできるのか？
それは、GeneXusにはWorkWithという万能画面が標準装備されているからです。
裏返すと、GeneXusによる作らない開発＝WorkWithを使ってWebPanelを使わないこと、
と短絡的に考える人も非常に多いわけですが、それは少し違って、まず構造で解決して
そこにWorkWithを適用することで、「作らないことを続けること」ができるのです。
WebPanelは構造を変えるとそれに従って手動で修正を当てなければいけませんが、
WorkWithは、一覧も関連ドリルダウン画面も全て新しい構造に自動で生まれ変わります。
トランザクションは当然構造に追随するので、WorkWithに紐づいている入力画面も自動で
変更される。開発者は(もしあれば)プロシージャの整合性を保つだけでよいのです。
もし、構造を優先しないで、WebPanelを作らない、WorkWithだけで作る、だけの方針でやって
いたら、構造に合わない画面が必要になっただけで簡単に破綻します。
じゃあそういう画面はWebPanel+SDTで作るか、と始まると、次から次へと作る画面が
増えていき、誰も構造を顧みなくなります。なぜなら、どう使われているかわからないから。
つまり、スパゲティ化です。
この微妙にずれた作らない開発をやっているところは意外に多いので、かなりの気合を
持ってコントロールしなければなりません。
構造と画面が直接結びついていると、それらを見ただけで仕様がわかります。
メンテナンスされていない仕様書に悩む必要もなくなるわけです。
業務が変わっても、それに構造を追随させ、画面が自動で再生成されれば、新しい業務に
どんどん対応できます。スパゲティ化しないのでシステムは常にきれいな状態で保たれ、
業務知識が常にKBに取り込まれた状態となる、再構築を必要としないレガシーレスの
システムが出来上がります。
これがまさに、GeneXusでいうところの「未来を守る」ことの真髄です。
ちなみに、WorkWithで自動生成されたオブジェクトやトランザクションのWebFormを改変して
「赤い状態」にすると、結局作る画面が増えていく上に、「どこがどう改変されているか、
もしくはされていないのかすらわからない」恐怖のKBとなっていきます。
だから、「絶対に赤くしてはいけない」のです。
どこかで、WorkWithという名前がついていながら全くトランザクションと関係のない「赤い」
画面がたくさんあるKBを見ましたが、あれはこれからどうメンテナンスしていこうというの
だろうか。。。